By default, the component functions are:
- Listens for the input message on the input port.
- Sends the output to JMSReplyTo if request reply is enabled on the input port which receives this message and JMSReplyTo is specified.
- If request reply is not enabled or JMSReplyTo is not specified then it sends the same message on all the output ports.
Business logic can be added to them in following ways depending on the type of component.
Adding Business Logic to Asynchronous Component
To add the business logic, first the control flow should be understood. The control flow works as mentioned as sections below:
Component Startup
- Component's 'Executable' class (present in ServiceDescriptor.xml) is invoked with required arguments in case of 'separate process' launch. Or, startup (String [] args) method of the component's 'InMemoryLaunchImpl' class (present in ServiceDescriptor.xml) passing the arguments.
- Arguments are parsed as in the figure below.
Figure 1: SampleEDBC.java showing the control flow entry point and the args passed
- The configuration of the component is serialized and bound using JNDI during the configuration time. This serialized configuration is looked up during the start up and de-serialized to get the configuration object.
Figure 2: SampleEDBC.java, JNDI lookup and deserialize the configuration
All the required JMS objects are created.
Component Runtime
- Once the component startup is complete, the component is ready to process the messages.
- Each of the input ports of the component is associated with a MessageListener (<Component_guid>MessageListner.java), which listens for the messages on the respective input port.
- On receiving a message, onMessage (Message msg) of MessageListener is called.
- The message is processed and sent on the output port(s) or JMSReplyTo destination as appropriate
Figure 3: SampleEDBCMessageListener.java containing logic to pass Object to request processor
Component shutdown
When the application / component is killed the component's process is killed and the component is forcibly killed. However, if the component is launched in memory the shutdown (Object hint) is called. All the JMS objects, connections and so on are closed here.
For the generated component all of the above work is done and only the business logic needs to be added. Business logic includes creating any necessary objects or connections to external systems required for processing the messages, processing messages and cleaning up the objects, created at startup, during the shutdown. Business logic can be added in processMessage(Message message) method of<component_guid> MessageListener .java as shown in Figures above.
Configuration Property Sheet in Asynchronous Component
The generated component by default has a Configuration Property Sheet (CPS), which can used to configure the adapter to perform required business logic. See section Adding properties to Configuration Property Sheet to add additional properties on the CPS.
In addition to getters and setters and the jmx-operations described in the Adding properties to Configuration Property Sheet (CPS) section, asynchronous components configuration class can have the following methods (jmx operations)
Adding Business Logic to Synchronous Component
The business logic of synchronous component lies in the <component_guid>Interaction.java. The methods and their purpose /description are given below:
String execute (ESBInteractionSpec interactionSpec, String inputMessage)
This method contains the business logic of the component.
Parameters:
- interactionSpec – the configuration object; holds all the details specified during the configuration time of the component in the Configuration Property Sheet (CPS).
- inputMessage – the inputMessage received on the component's input port
Return value:
Returns the string which should be sent as output message on the output port of the component.
ESBRecordDefinition getInputRecordDefinition(ESBInteractionSpec interactionSpec)
This method sets the schema (XSD/DTD) of the expected input message on the input port of the component
Parameters:
- interactionSpec – the configuration object; holds all the details specified during the configuration time of the component in the Configuration Property Sheet (CPS).
Return value:
Returns a ESBRecordDefinition object which contains the schema details like, the structure, structure type (XSD/DTD), root element, targetnamespace if the structure is a XSD and the imported XSDs if any in case the structure type is XSD.
ESBRecordDefinition getOutputRecordDefinition(ESBInteractionSpec interactionSpec)
This method sets the schema (XSD/DTD) of the expected output message on the output port of the component
Parameters:
- interactionSpec – the configuration object; holds all the details specified during the configuration time of the component in the Configuration Property Sheet (CPS).
Return value:
Returns a ESBRecordDefinition object which contains the schema details like, the structure, structure type (XSD/DTD), root element, targetnamespace if the structure is a XSD and the imported XSDs if any in case the structure type is XSD.
Figure 4: SampleBCInteraction.java showing the business logic
Adding properties on response message
To add properties on to the response (output message) for a request make the following change in the <component_guid>Interaction.java
Add the following code in the <component_guid>Interaction class as shown in Figure below.
Figure 5: code snippet to be added in SampleBCInteraction.java to read/set properties on the message
Javadoc for API to add the properties on the ESBRecord is present at the following location %FIORANO_HOME%/javadoc/BCDK/index.html
Returning multiple responses for a single request
To return multiple responses for a single request
- Create a class which implements EnumerationRecord and implement hasMoreElements () and nextElement () method (shown in Figure below)
- hasMoreElements () should return if more output messages exist
- nextElement () should contain logic for processing/retrieving next output message
Figure 6: EnumerationRecord Implementation
- Add the code snippet shown in Adding properties on response message section make the following change in the <component_guid>Interaction.java
- Add the following code in the <component_guid>Interaction class as shown in Figure below.
Figure 7: Code to be added in SampleBCInteraction.java for supporting multiple responses
Handling Connection
<component_guid>EISConnection.java creates and holds (in m_physicalConnection object) the component's connection to EIS. Figure below shows the code snippet where the connection creation has to be added. The user does not take to implement connection pooling. The framework automatically allows pooling of connections.
Figure 8: SampleBCEISConnection.java showing location for connection creation
Adding Business Logic to C Components
The purpose of the source files generated is explained below:
- The {ServiceGUID}.c contains the main() function which creates a connection with the peer server by calling the method initializeConnection.
- When a message is received on the input port of the component, the function onMessage is called which in turn calls the function processMessage to process the message.
Figure 9: onMessage and processMessage methods
The functionality of the business component can be defined in the processMessage method.
Adding Business Logic to C++ Component
The purpose of the source files is explained below along with the control flow
The file {ServiceGUID}main.cpp contains the main function where all the required JMS objects are created and the service is started.
The generated main method is shown below:
When a message is received on the input port of the component, the function onMessage defined in {SerivceGUID}.cpp will be called and the business logic of the component can be defined in this method. (See Figure below)
Figure 10: Default contents of the onMessage method of {ServiceGUID}.cpp
Adding Business Logic to C# Component
By default, the component sends the messages received on its input port to the output port. Custom component generation wizard creates a visual studio solution file (.sln) which can be opened using Microsoft Visual Studio 2003 or above.
Figure 11: Structure of asynchronous component
The main method in {ServiceGUID}Main creates all the required JMS objects and starts the component. The Message Listener ({ServiceGUID}MessageListener) contains the callback method onMessage. For each message received on the input port of the component, onMessage function is called and this calls processMessage function. The business logic can be provided in the method processMessage.
Figure 12: Default contents