-
- .. container:: title
-
- Field Schema types
-
- .. container:: paragraph
-
- APEX natively supports schema definitions in ``Java`` and ``Avro``.
-
- .. container:: paragraph
-
- ``Java`` schema definitions are simply the name of a Java Class. There are some restrictions:
-
- .. container:: ulist
-
- - the class must be instantiatable, i.e. not an Java interface or abstract class
-
- - primitive types are not supported, i.e. use ``java.lang.Integer`` instead of ``int``, etc.
-
- - it must be possible to find the class, i.e. the class must be contained in the Java classpath.
-
- .. container:: paragraph
-
- ``Avro`` schema definitions can be any valid `Avro <https://avro.apache.org/docs/current/spec.html>`__
- schema. For events using fields defined with ``Avro`` schemas, any incoming event containing that field must
- contain a value that conforms to the Avro schema.
+
+ .. container:: title
+
+ Field Schema types
+
+ .. container:: paragraph
+
+ APEX natively supports schema definitions in ``Java`` and ``Avro``.
+
+ .. container:: paragraph
+
+ ``Java`` schema definitions are simply the name of a Java Class. There are some restrictions:
+
+ .. container:: ulist
+
+ - the class must be instantiatable, i.e. not an Java interface or abstract class
+
+ - primitive types are not supported, i.e. use ``java.lang.Integer`` instead of ``int``, etc.
+
+ - it must be possible to find the class, i.e. the class must be contained in the Java classpath.
+
+ .. container:: paragraph
+
+ ``Avro`` schema definitions can be any valid `Avro <https://avro.apache.org/docs/current/spec.html>`__
+ schema. For events using fields defined with ``Avro`` schemas, any incoming event containing that field must
+ contain a value that conforms to the Avro schema.
- .. note::
- .. container:: title
-
- State Output Mappings
-
- .. container:: paragraph
-
- In a 'Policy' 'State' a 'State Output Mapping' has 3 roles:
- 1) Select which 'State' should be executed next, 2) Select
- the type of the state’s 'Outgoing Event', and 3)
- Populate the state’s 'Outgoing Event'. This is how states are
- chained together to form a (`Directed Acyclic Graph
- (DAG) <https://en.wikipedia.org/wiki/Directed_acyclic_graph>`__ )
- of states. The final state(s) of a policy are those that do
- not select any 'next' state. Since a 'State' can only
- accept a single type of event, the type of the event emitted
- by a previous 'State' must be match the incoming event type
- of the next 'State'. This is also how the last state(s) in
- a policy can emit events of different types. The 'State
- Output Mapping' is also responsible for taking the
- fields that are output by the task executed in the state and
- populating the state’s output event before it is emitted.
-
- .. container:: paragraph
-
- Each 'Task' referenced in 'State' must have a defined
- 'Output Mapping' to take the output of the task, select an
- 'Outgoing Event' type for the state, populate the state’s
- outgoing event, and then select the next state to be
- executed (if any).
-
- .. container:: paragraph
-
- There are 2 basic types of output mappings:
-
- .. container:: olist arabic
-
- #. **Direct Output Mappings** have a single value for
- 'Next State' and a single value for 'State Output
- Event'. The outgoing event for the state is
- automatically created, any outgoing event parameters
- that were present in the incoming event are copied
- into the outgoing event, then any task output fields
- that have the same name and type as parameters in the
- outgoing event are automatically copied into
- the outgoing event.
-
- #. **Logic-based State Output Mappings / Finalizers**
- have some logic defined that dynamically selects
- and creates the 'State Outgoing Event', manages
- the population of the outgoing event parameters
- (perhaps changing or adding to the outputs from the
- task), and then dynamically selects the next state to
- be executed (if any).
+ .. note::
+ .. container:: title
+
+ State Output Mappings
+
+ .. container:: paragraph
+
+ In a 'Policy' 'State' a 'State Output Mapping' has 3 roles:
+ 1) Select which 'State' should be executed next, 2) Select
+ the type of the state’s 'Outgoing Event', and 3)
+ Populate the state’s 'Outgoing Event'. This is how states are
+ chained together to form a (`Directed Acyclic Graph
+ (DAG) <https://en.wikipedia.org/wiki/Directed_acyclic_graph>`__ )
+ of states. The final state(s) of a policy are those that do
+ not select any 'next' state. Since a 'State' can only
+ accept a single type of event, the type of the event emitted
+ by a previous 'State' must be match the incoming event type
+ of the next 'State'. This is also how the last state(s) in
+ a policy can emit events of different types. The 'State
+ Output Mapping' is also responsible for taking the
+ fields that are output by the task executed in the state and
+ populating the state’s output event before it is emitted.
+
+ .. container:: paragraph
+
+ Each 'Task' referenced in 'State' must have a defined
+ 'Output Mapping' to take the output of the task, select an
+ 'Outgoing Event' type for the state, populate the state’s
+ outgoing event, and then select the next state to be
+ executed (if any).
+
+ .. container:: paragraph
+
+ There are 2 basic types of output mappings:
+
+ .. container:: olist arabic
+
+ #. **Direct Output Mappings** have a single value for
+ 'Next State' and a single value for 'State Output
+ Event'. The outgoing event for the state is
+ automatically created, any outgoing event parameters
+ that were present in the incoming event are copied
+ into the outgoing event, then any task output fields
+ that have the same name and type as parameters in the
+ outgoing event are automatically copied into
+ the outgoing event.
+
+ #. **Logic-based State Output Mappings / Finalizers**
+ have some logic defined that dynamically selects
+ and creates the 'State Outgoing Event', manages
+ the population of the outgoing event parameters
+ (perhaps changing or adding to the outputs from the
+ task), and then dynamically selects the next state to
+ be executed (if any).