Index Changes

Difference between version and version     

Back to Fuji EIP Split, or Fuji EIP Split Info


At line 1 added 1 line.
[{Image src='fuji-logo8.gif' link='https://fuji.dev.java.net/' alt='Fuji Home' align='left'}]
At line 7 added 2 lines.
The purpose of the split pattern is to take a single input message and output one or more output messages based on a boundary condition. The boundary condition can be specified in a wide variety of languages and is generally tied to the type of data being split (e.g. XML -> XPath). Some split expressions are more powerful than others, with the option to mangle or enrich the data as a side effect of being split.
\\
At line 12 added 1 line.
The split pattern is very common in the integration space, particularly in batch-oriented environments. Some of the more common use cases follow (feel free to add your own!).
At line 10 changed 1 line.
! Enveloped Data
Take a large input message and split it into more digestible pieces, also known as chunking. This allows for more efficient memory utilization, as chunked pieces can be reclaimed by the garbage collector individually. Chunking also allows for a divide and conquer approach, where parallel processing results in faster overall throughput for a given message size.
At line 16 added 5 lines.
A message needs to be unwrapped into individual pieces so that each piece can be processed by the appropriate message stream. Commonly paired with content-based routing.
! Enveloped Data
Refinement of dispatch centered around an envelope structure in the input message. A classic example of this use case is receipt of an ANSI X12 EDI message which contains multiple transaction types inside a single input message. Split can be used to break out each transaction type and forward on to the appropriate back-end processing system.
! Keep the Baby, Lose the Bath Water
Avoids situations where a large message is completed rejected due to one or two bad records.
At line 56 changed 1 line.
Each split type will have its own unique configuration requirements. The service artifact layer in Fuji will have a reasonable default behavior for all split types. Individual split types can override the default behavior by implementing the following contracts:
Each type implementation will have its own specific configuration. There however is a configuration which can be defined for all types in general:
|| Attribute || Description || Default
|''batchSize'' | Limits the of output messages that are processed in parallel. | Default is 1000. If the inbound message exchange is transactional (I.E. MessageExchange.isTransacted() returns true) the batchSize is forced to 1
The service artifact layer in Fuji will have a reasonable default behavior for all split types. Individual split types can override the default behavior by implementing the following contracts:
At line 76 changed 1 line.
<item>bang001</id>
<item>bang001</item>
At line 81 changed 1 line.
<item>parkayXYZ</id>
<item>parkayXYZ</item>
At line 94 changed 1 line.
<item>bang001</id>
<item>bang001</item>
At line 102 changed 1 line.
<item>parkayXYZ</id>
<item>parkayXYZ</item>
At line 117 changed 1 line.
<item>bang001</id>
<item>bang001</item>
At line 122 changed 1 line.
<item>parkayXYZ</id>
<item>parkayXYZ</item>
At line 137 changed 1 line.
<item>bang001</id>
<item>bang001</item>
At line 148 changed 1 line.
<item>parkayXYZ</id>
<item>parkayXYZ</item>
At line 205 removed 3 lines.

JSPWiki v2.4.100
[RSS]
« Home Index Changes Prefs
This page (revision-14) was last changed on 21-Jul-09 09:42 AM, -0700 by MarkWhite