Home
Modules
Project Documentation
Development
Design
- Components
Events are responsible for message creation.
listen
A listener awaits a message on the supplied URL.
<!--
This starts a listener which will wait for messages and field them
straight to the specified group. In this case the nested group.
-->
<listen url="jms://entryPointForPipeline">
<group execution-model="direct" exception-model="abort">
<service url="sca://myService2"/>
<service url="java://myService3"/>
<service url="sca://myService4">
<!--
A stateful service is passed it's state as well as the
incoming message.
-->
<state url="local://service4State"/>
</service>
</group>
</listen>
poll
A poller checks repeatedly for messages on the supplied URL.
time
A timer sends heartbeat messages at the scheduled times.
A processing group consists of processing instructions each of these instructions accepts a message in and passes it out again, while it has access to the message it may also chose to pass it to any of the nested processing instructions if it supports nested processing instructions. The means for executing the next processing instruction is determined by the execution-model attribute and what to do if an exception occurs is determined by the exception-model attribute.
If in doubt about all this works, just think of chaining Un*x commands together with pipes.
The first element in a processing group is usually executed from a listener or from a call. Depending on the model used one or more may be executed simultaneously, when the instruction completes the result is passed to the next processing instruction via the group.
get
Get performs a blocking read on the supplied url and returns when the resource returns.
poll
A poll processing instruction ignores all input and polls one or more resources. On receipt of a message it passes the message to the next in the group.
<poll><url>http://server1/myThing</url><url>http://server2/myOtherThing</url></poll>
<poll url="http://server1/myThing"/>
dispatch
The dispatch processing instruction sends a copy of the received message to the supplied URL or URLs and then passes the received message to the next processing instruction.
balance
The balance processing instruction specifies that a load-balancing strategy should be used to decide which of the supplied URLs to send to. If sync="true" is says
send
The send processing instruction sends a copy of the received message to the supplied URL or URLs and then passes the result of sending the message to the next processing instruction. The send processing instruction also supports a nested balance instruction.
wait
The wait processing instruction awaits the completion of it's inner element.
<wait><poll url="jdbc:select * from LOCK_TABLE"/></wait>
while
The while processing instruction takes the result of the last of it's inner processing instructions and passes it to the first unless the URL provides a negative response.
<!-- This repeats while the URL provides a positive response -->
<while url="groovy:text:counter < 10">
<!-- A processor is a general processing component and is allowed to
do anything it likes with the message it receives, this is a catch
all to allow for any scenarios not supported by core components. It
can have any processor element nested within it also.
-->
<processor url="java://org.me.RawMessageProcessor"/>
<!-- Wait until a message is received on the URL -->
<wait>
<get url="time:1000ms"/>
</wait>
</while>
conditional
With a conditional the query specified will be executed before each of the nested instructions. If the query returns true then the next instruction will be executed and so on.
<conditional>
<url>groovy:text:message.exceptionState.exceptionList.isEmpty</url>
<send url="system://sedaProcessingEntryPoint1"/>
<send url="system://sedaProcessingEntryPoint2"/>
<send url="system://sedaProcessingEntryPoint3"/>
</conditional>
call
The call processing instruction is used to execute another Einstein processing group from the current group.
split
A splitter applies the supplied query to the incoming message and takes the result of the query and passes each element one at a time to the nested processing instruction(s).
parallel
This instruction executes the sub instructions in parallel. By setting wait="true" and aggregate="true" it can apply the scatter-gather pattern by sending the message to all the nested instructions. When all of the nested instructions have returned results the results are combined together and passed to the next processing instruction. Optionally a query can be specified to split the inbound message in which case the split messages will be passed to each of the group in turn - (useful for distributing work).
<!--
The parallel processing instruction will execute each group member
asynchronously. If wait is set to true then it will wait
for completion of all the instructions in the group. If aggregate
is set to true then the results of each of instruction will be
put into a List and used as the message payload.
-->
<parallel wait="true" aggregate="true">
<group>
<send url="system://sedaProcessingEntryPoint1"/>
<send url="system://sedaProcessingEntryPoint2"/>
<send url="system://sedaProcessingEntryPoint3"/>
</group>
</parallel>
aggregate
The aggregator applies the partition computation to incoming messages which evaluates a string naming the partition under which the messages can be aggregated. The supplied store element decides where the messages will be stored. In the release element the criteria for releasing the contents of a partition is supplied. If the release criteria is not met then the next instruction will not be called, if it is then the aggregated result from that bucket will be passed to the release instructions nested instruction(s).
<!--
An aggregator stores up messages until the release criteria is reached
in which case the payloads are joined and then passed to the
release elements nested processing instructions.
-->
<aggregate>
<partition url="xpath:///thing/thang"/>
<store url="dynamic:javaspaces://aggregationStore//${partitionName}"/>
<!--
On release the nested elements are called, the partitionName will
be in the processing context.
-->
<release url="groovy:text:size > 3">
<!--
Retrieve goes to the specific URL with a blocking read.
-->
<retrieve url="dynamic:javaspaces://aggregationStore/${partitionName}"/>
<!--
Map converts a list of data into a map using the supplied
queries to obtain the key and value.
-->
<map key="groovy:text:message.payload.name" value="builtin:payload"/>
<!--
A reduction takes a map of data, passes it to an algorithm which then
reduces the size of the map.
-->
<reduce url="java:org.me.MyReductionAlgorithm">
<!--
The recurse opeartion calls it's parent with the current mesage until
the optional url supplied becomes false a maximum depth can be specifed
(the default is a finite number).
-->
<recurse url="groovy:text:mesage.payload.list.size() < 1"/>
<send>axis:http://myserver.com/myService</send>
</reduce>
</release>
</aggregate>
switch
A switch contains a set of cases if the value from the url that switch acts upon is equal to the value of a case it's contents will be executed.
<switch id="switch" url="groovy:text:payload.thing">
<case value="2">
<dispatch id="1" url="system://sedaProcessingEntryPoint1"/>
</case>
<case value="3">
<!--
The parallel processing instruction will execute each nested instruction
asynchronously. If wait is set to true then it will wait
for completion of all the instructions in the group. If aggregate
is set to true then the results of each of instruction will be
put into a List and used as the message payload.
-->
<parallel wait="true" aggregate="true">
<send url="system://sedaProcessingEntryPoint1"/>
<send url="system://sedaProcessingEntryPoint2"/>
<send url="system://sedaProcessingEntryPoint3"/>
</parallel>
</case>
</switch>
choose
The choose instruction executes a query against the incoming object and the list of available choices, the result will be the ids of the nested processing instructions to send the message to. When the choose has finished executing the original message is passed onto the next processing instruction.
<!-- A choice is similar to a switch except it allows the quick identificaton
of multiple instructions to be executed.
-->
<choose url="groovy:text:payload.thing.name">
<!--
The query will be passed all routes as an array and will return
zero or more IDs as a result.
-->
<choices>
<dispatch id="albert" url="system://sedaProcessingEntryPoint1"/>
<dispatch id="dave" url="system://sedaProcessingEntryPoint2"/>
<service id="john" url="java://thing"/>
<switch id="switch" url="groovy:text:payload.thing">
<case value="2">
<dispatch id="1" url="system://sedaProcessingEntryPoint1"/>
</case>
<case value="3">
<!--
The parallel processing instruction will execute each nested instruction
asynchronously. If wait is set to true then it will wait
for completion of all the instructions in the group. If aggregate
is set to true then the results of each of instruction will be
put into a List and used as the message payload.
-->
<parallel wait="true" aggregate="true">
<send url="system://sedaProcessingEntryPoint1"/>
<send url="system://sedaProcessingEntryPoint2"/>
<send url="system://sedaProcessingEntryPoint3"/>
</parallel>
</case>
</switch>
</choices>
</choose>
filter
The filter is executed against the inbound message and if it evaluates to true then the next processing instruction is executed with the inbound message otherwise no action is performed.
assert
An assertion is the same as filter except if it is false an exception in the processing is generated and the action determined by the exception-model is taken. Assertions can be turned off at runtime.
enforce
An enforce instruction is the same as an assertion except it cannot be switched on or off at runtime.
process
This is the catch-all instruction which is simply passed all the nested processing instructions and can decide what to do with them itself
transform
A transformer converts the inbound message from one form to another, strictly speaking it should not affect the contained data but merely how it is arranged. Transformation does not include translation to a new data model, translation is performed by entering a group with a new data model.
<transform url="ref:Object2String"/>
service
A service is passed the inbound message and the result of execution is passed to the next component. A service can be passed different parts of the Message state depending on the use attribute, either the entire message state, the payload and enrichments or just the payload.
enrich
An enricher takes the inbound message and adds additional enrichment information to the message. The enricher specifies a path to the node which will have the children added to.
<enrich path="xpath://message/payload/order/line[type=software]/productDetails"
parallel="true">
<group>
<poll url="axis://myserver.com/myService"/>
<transform url="java:org.me.MyService"/>
<service url="java:org.me.MyService"/>
</group>
</enrich>
process
A process is the same as mentioned in 'Routing Style instructions'.
mutex
Only one instance of this with a matching partition (defined by the URL) can be executed in the scope specified. Establishing the mutex lock is the responsibility of the execution model.
<!--
The following should be run only once in the specified scope.
-->
<mutex scope="domain" url="text:MySingletonService">
<service idempotent="true" url="sca://MySingletonService"/>
</mutex>