Anatomy of a service
To make use of a service, three parts are required:
1. A set of smart blocks to expose functionality to scenarios. Scenarios write to a single set of blocks, regardless of the mechanism providing the functionality.
2. An interface EPL file. This defines the interface for blocks to talk to services.
3. One or more service monitors. These implement the functionality, either as a simulation inside the correlator, or by providing an interface and managing access to an adapter. Some service monitors may implement more than one function.
The Legacy Finance Support bundle, provided with the CMF, contains the interfaces your application needs to make use of a service as described in this section. Consequently, in Software AG Designer, be sure to add the Legacy Finance Support Bundle to your project.
Addressing services
Most simple applications will require a single service to implement a given function in production, but may want to use a simulation in the initial stages of development. In this case, the service identifier supplied to the block may be left blank. This means that any service monitor may service the block. In development, a simulation service monitor can be injected into the correlator. In a production environment, the same scenario is loaded into a correlator along with an adapter service monitor, and the adapter service monitor will be used.
If the service identifier is left blank, any service loaded is used to service the block’s request. Note that in this case it is an error to load more than one service monitor that implements the same functionality.
More complex applications may wish to make use of more than one interface for a function (for example, place orders against two markets, one accessed through GL and another through FIX). In this case, multiple services must be loaded into the correlator, so a block must distinguish which one it is intended to communicate with. To talk to a specific service, set the service identifier to the name of the service.
Optional and extra parameters
Some aspects of functionality vary from service to service. Some services may ignore some parameters; others require parameters that are specific to that service. Service specific parameters that are not included in the block interface may be passed to the service using the extra parameters block parameter. This is a string that has a variable number of name and value pairs encoded within it. The order of the names is not relevant. The string has the format:
Name1=value1;Name2=value2;
For example, an order manager may require a username and password to be passed to it; in this case, the extra parameter may look like:
Username=joebloggstrader;Password=passw0rd;
Some blocks also provide an extra parameters field in their output feed. By convention, the names of extra parameters use TitleCase; that is, there are no spaces or other punctuation in the names, but the first character of every word is capitalized. For example, you might specify the name of an extra parameter as ObjectId. Note that when the name of an extra parameter includes an ID, the convention is to specify it as Id.
To aid in handling these strings, there are 3 functions available in Event Modeler:
ADD_EXTRAPARAM ( text, text, text )
Takes an existing extra-parameters string (or an empty string), and a name and value pair to add to it; returns text.
HAS_EXTRAPARAM ( text, text )
Takes an extra-parameters string and a name, and returns true if the name is in the extra-parameters string and false otherwise.
GET_EXTRAPARAM ( text, text )
Takes an extra-parameters string and a name, and returns the value from the extra parameters string or an empty string if it does not exist. To distinguish between not present and present but empty value, use the HAS_EXTRAPARAM ( text, text ) function.
For example, to place an order with the above example username and password, and update the status variable if the order status contains the extra parameter ThirdPartyChange:
Submit order with username and password |
i | Set the Order Manager's extra parameter to the username and password "joebloggstrader" and "passw0rd", and then place the order (assume all other parameters have already been set). |
When | true |
Then |  extra parameters from Order Manager = ADD_EXTRAPARAM ( ADD_EXTRAPARAM ( "", "Username" , "joebloggstrader" ) , "Password" , "passw0rd" )submit order [Order Manager] remain in this state |
Wait for ThirdPartyChange message |
i | Wait until the order service has provided a ThirdPartyChange message, and display it through the status scenario variable once received. Clear the output feed so any further messages are shown too. |
When | HAS_EXTRAPARAM (extra parameters from Order Manager (order status), "ThirdPartyChange" ) |
Then | status = CONCAT ( 'Third Party order modification ', GET_EXTRAPARAM ( extra parameters from Order Manager (order status), "ThirdPartyChange" ) ) clear [Order Manager] remain in this state |
Note the nesting of ADD_EXTRAPARAM to create an extra parameters string with two parameters. This rule could have been written:
Submit order with username and password |
i | Set the Order Manager's extra parameter to the username and password "joebloggstrader" and "passw0rd", and then place the order (assume all other parameters have already been set). |
When | true |
Then | extra parameters from Order Manager = ADD_EXTRAPARAM ( "", "Username" , "joebloggstrader" ) extra parameters from Order Manager = ADD_EXTRAPARAM ( "Password" , "passw0rd" ) submit order [Order Manager] remain in this state |
