Last time we looked into what ISO 8583 is, the message and field structures, and how to use the example base schemas to work with the financial messages within Rational® Integration Tester. In this article we will step through an example scenario, to do this we are imagining an ATM (Automatic Teller Machine) connecting through a TCP network to a core banking system, we will look at modelling this and how to test and simulate an ISO 8583 transaction message step by step.
Configuring the proxy
In our imaginary system the ATM normally connects to the core banking system over TCP on port 60000, in order for us to be able to observe communications we need to configure the RIT proxy server appropriately and have the client application address this instead. We do this by adding forwarding rule to RIT HTTP/TCP proxy:
- Using any text editor, open the registration.xml file that is available in <Rational Integration Tester Platform Pack installation directory>/httptcp location
- Add a TCP forwarding rule for the destination address and specify the proxy port.
Note: The host name or the IP address specified for the bind attribute determines which network interface the proxy will listen on. We use the following:
<forward bind=”localhost:55555″ destination=”localhost:60000″ />
- Save your changes and restart the RIT HTTP/TCP proxy server.
Modelling the System Under Test
In Rational Integration Tester we start by modelling the system under test, for this we use components, operations and logical connections to endpoints that are used by tests and stubs so that those assets are reusable across multiple environments.
- Open the Logical View of the Architecture School perspective of Rational Integration Tester
- On the toolbar of the Logical View, click General >Service Component. Enter a name for service component that we are creating, we use “Cash Machine” in this example
- Make sure the newly created component is selected
- Next, click General > TCP Connection to create a TCP Connection, the new resource window is displayed. Enter a name for the connection and click OK, we use “ATM Network” in this example
- A corresponding Physical resource will have been created for our current environment
Configuring the physical TCP Server
As the physical resource has been created we can now update the settings that represent the end point within this environment.
- Staying in the Logical View of the Architecture School perspective, Right-click on “ATM Network” TCP Connection and click “Physical Resource” in the pop-up menu
- The Name field will have the same value as the logical resource, you can change this something more meaningful for this connection or clear it out as desired
- Click Settings, fill the Hostname and port. These settings are used to create the rule that defines what TCP traffic to record. For our example:
- Click Client to configure the proxy settings of the transport, this allows RIT to send its traffic via the proxy and allows us to observe what is happening more easily. For example:
- Click Packetizer to configure the application layer settings of the transport. Select Type as “Length”, check the “Update outbound message with packet details below” check box so that messages RIT generates will have the correct values set.
- Keep other options as default and click OK.
Defining an operation to test and virtualize
Now that we have our Cash Machine component we can model one of the operations that it provides.
- Select the “Cash Machine” component
- Add an operation by clicking General > Operation. Fill in a suitable name “Withdrawl”.
- Double click the new resource to configure the settings
- Under the Message Exchange Pattern tab, select Binding Transport as “ATM Network” and schemas for the Request/Reply model using the ISO 8583 schema that you imported from the earlier article
- Click OK and we have our system modeled.
Creating a stub from MEP
As we have no existing system in our example we will start by creating a virtual service that provides the “Withdrawl” functionality in the system that we have just modeled.
- Open the Test Factory perspective, select the operation that the stub will be for
- Right-click the operation and select New > Stubs > Stub using MEP from the menu
- Provide a name for the new stub when prompted, here we use “Funds Available” as the example name, click OK. The new stub is opened for editing and includes a transition for the selected operation
- The Input tab shows the basic message header fields and describes the conditions under which this stub will provide a response
- Click the Activity tab to show the response that will be issued, right-click on the “ISO8583_1987_ASCII” field
- Select Add Child >
and fill in the value of the field
- Repeat this until all your required fields are added (the details of this will depend on the rules of the provider that you are working with).
Creating a test from MEP
Now that we have a stub to emulate the withdrawl functionality we can now write a test to simulate the behavior of the user performing that task from the ATM. As with the creation of the stub we can leverage the fact that we have modeled an operation and have the actions automatically added to a test asset.
- Open the Test Factory perspective, select the operation that the test will be for
- Right-click the operation and select New > Tests > Test using MEP from the menu
- Provide a name for the test, here we use “Withdraw cash” as the example name, click OK. The new test is opened for editing and contains the request and response actions
- Open the Send Request test step, you should see the ISO8583 schema should be applied to the data node in message field tree automatically
- As with creating the stub earlier, right click on the â€śISO8583_1987_ASCIIâ€ť node and use “Add Child” to add data elements of ISO 8583 Cash Withdrawal request message one by one
- Now do the same for the response message, populating it with the fields that you would expect to receive, in this scenario from the stub
Running and Recording
We should now have everything in place to allow us to virtualize, test and record the interactions that take place between our simulated system.
- Open the Test Lab perspective, select the stub that we created earlier
- Right-click and select “Run” from the menu
- Now repeat this for the Test that was created
- You should see two entries in the task view and if everything is working the stub will show a count of 1 where it has provided the response.
- Open the Architecture School perspective, select the operation that we modeled
- Right-click and select “Add event monitor” from the menu
- You will be taken to the Recording Studio perspective with the operation listed in the Monitor Configuration View
- In the Events View panel, click the red “Start Recording” button to instruct the proxy to send copies of the events it sees back to us
- Re-run the test that we ran earlier and then return to the Recording studio to confirm that we can captured a copy of the two messages
Hopefully the creation and execution of tests and stubs is something that is well understood, more important to take away is an understanding of how the physical transport needs to be configured to allow the data stream that carries the messages to be packetized so that tests, stubs and the recording studio is able to be break them down into individual ISO 8583 messages irrespective of how the data is presented on the wire. We have also looked at how the proxy can be configured to forward traffic it receives onto the intended destination allowing a client application to leverage the recording and virtualization capabilities or Rational Integration Tester.
Next time out we will look at how to work with an existing system and the changes that can be made to the ISO 8583 schemas to allow custom variants to be interpreted.