The Join component can be used to join two input XML structures using the Fiorano Mapper into one output XML. This component has two input ports and three output ports. The two input ports, IN_PORT1 and IN_PORT2 are used to input the two XML structures that have to be joined. After the Join operation is performed, messages are sent to each of the output ports.

• Message received on input IN_PORT1 is sent to the output port OUT_PORT_IN1
• Message received on input IN_PORT2 is sent to the output port OUT_PORT_IN2
• The result of the Join operation is sent to the output port OUT_PORT_RESULT

When the component receives a message on one of the input ports, it checks if there are messages that are received on the other port which are not already used in Join operation.

• If there are no messages that are received on the other port and are not already used in Join operation, the message received is added to an internal queue. There is a separate queue for each input port that holds messages until the Join operation is performed.
• If there are messages received on the other port which are not already used in the Join operation, then the first message is picked from the queue and the Join operation is performed.

Configuration and Testing

The Join component can be configured using its Custom Property Sheet as shown in figure 1.

Figure 1: Join configuration property sheet

Mappings

The mappings between input and output structures can be defined by clicking on the ellipsis button against this property. Fiorano Mapper gets launched upon clicking the ellipsis as shown in figure 2.

Figure 2: Configuring mappings using Mapper

XSLT engine for the Join operation can be specified by this parameter. Join operation is performed using a XSLT. The component can be configured to use a specific XSLT engine to perform XSLT. Xalan (2.7.0) and Saxon (8.4) transformer implementations are bundled with Fiorano environment for performing transformations. By default, the component uses Xalan.

• Xalan
  Xalan implementation (org.apache.xalan.processor.TransformerFactoryImpl) is used to perform transformation. 

  Icon

  Xalan (2.7.0) does not support XSLT 2.0

• Saxon
  Saxon implementation (net.sf.saxon.TransformerFactoryImpl) is used to perform transformation. 

  Icon

  Saxon implementation does not support custom functions.

• Other
  This option should be used when a custom transformer implementation has to be used.

  Icon

  Selecting this option enables the property Transformer factory class Name which can be used to provide the transformation factory implementation that should be used.

Transformer factory class Name

This property determines the fully qualified name of the class which should be used to perform transformation when the property XSLT Engine is specified as Other. The class provided should be an implementation of javax.xml.transform.TransformerFactory.
Resources (jar files) containing the java class specified against this property should be added as resources to Join component.

Use context value from

This property determines the input port from which the value of the application context has to be picked. This value is set on the joined message coming out of OUT_PORT_RESULT port. One of IN_PORT1 or IN_PORT2 can be chosen.

Use properties and headers from

This property determines the input port from which the headers / properties have to be picked up and set on the joined message coming out of OUT_PORT_RESULT port. If either IN_PORT1 or IN_PORT2 is chosen, properties are fetched form the chosen port and properties from the other port are discarded. If BOTH is chosen, properties from both the ports are set on the joined message.

Prefer Properties and Headers from

When the property Use properties and headers from is set as BOTH and if there are headers / properties with same name on both IN_PORT1 and IN_PORT2 with different values, the port from which the values of such headers / properties have to be picked up and set on the joined message is determined by this property.

Message matching configuration

Figure 3: Message Matching Configuration

The second panel defines the way messages coming on input ports have to be matched.

Criterion to join messages

The messages can be matched based on different criteria as below:

• NONE
  Messages will be joined in the order in which they come onto the input port without checking for any condition.

  Icon

  In this case, the unjoined messages will be present on the input ports of the component and on failover/restart of the component, the messages will not be lost.

• Property
  The messages are joined based on the value of the JMS properties on either ports. The names of the properties can be configured using attributes Property name for messages on Input Port 1 and Property name for messages on Input Port 2. The messages with same value for the respective properties are joined.
  
  

• XPath
  The messages are joined based on the value of the element in the input XML at the XPath specified. The XPaths can be configured using attributes XPath for messages on Input Port 1 and XPath for messages on Input Port 2. The messages with same value at respective XPaths are joined.

  Icon

  If the value(of XPath/Property) does not match, the message will be stored inmemory/database. When a matching message comes on the other port later, this message will be joined with that. If multiple messages are stored for a matching message on other port, then they are retrieved in order in which they are received by the component.

Store unjoined messages

When PROPERTY/XPATH is chosen as joining criterion, the messages will be received by the component as they come and maintained in an internal store till a matching message comes. So the messages will get lost if the component is restarted. If this option is chosen the messages are stored in an internal Mckoi DB.

Table name Prefix

The prefix for the table name used for storing the messages. Two tables with <Prefix>_<Input Port Name> will be created for persitence. If left empty, <EventProcessGUID><Service name> will be used.

Testing

Join component is configured as shown in Figure 2 and the transformation can be tested from Mapper using the Test XSL button.

Sample Schema for Input XML Message 1

Figure 4: Sample Join input 1 message

Sample Schema for Input XML Message 2

Figure 5: Sample Join input 2 message

Figure 6: Sample Join output message

Functional Demonstration

Scenario 1

Send two different messages for which mapping is configured in the Join component and displaying the response message.
Configure the Join as described in Configuration and Testing section and use Feeders and Display component to send sample input and check the response.

Figure 7: Demonstrating Scenario 1 with sample input and output

Sample Input

Input 1

 

Input 2

Sample Output

Useful Tips

• It is advised to configure the components connected to IN_PORT1, IN_PORT2 and OUT_PORT_RESULT of the Join component before configuring Join component. This allows join component to pick input and output structures appropriately. Input and output structures can also be provided in the CPS of Join. But, to make sure there are no schema mismatches after configuring all components, it is suggested to configure the components connected to this component before Join is configured
• More than three input structures (including Application Context) and one output structure cannot be added.
• Only after Join component receives at least one input message on each input port, it will perform the join operation and sends message onto output ports. If ten messages are received on the first input port and five on the second input port or vice versa, then the join is performed five times.