In this article we’ll present basic testing concepts, using BP-Source module. We’ll also do a brief excursion into BP-Sim configuration options.
BP-Source is the first of many BP-Sim‘s modules. This module was developed to simulate sources of payment transactions in many ways and also to provide analytic information about transactions carried. Let’s have a look how to setup basic BP-Source configuration and how to run a basic test.
As the first we need to have BP-Sim running. BP-Sim is front-end framework, which allows easy setup, configuration overview, test management and access to testing output. Majority of tests are run through this console, while in some special cases other methods can be used. These cases will be explained in a different article.
BP-Sim usually opens showing a Source control screen. This is a main screen for interaction with the test. You can simply hit the Start button now and see what happens, but before doing it I would recommend having a look around the test configuration available. First thing we need to setup is transaction source. This so called Source gathers all devices and manages them. Let’s have a look how to do it.
Use a tree menu located on the left part of the screen and unfold the Sources option. Here you can see a list of all available Source configurations (see screenshot below). These configurations are named by the transaction format used and a star sign ‘*’ in the source label indicates which configuration is currently active. Detailed source configuration is explained in the user guide so we’ll go through it just very briefly. Most important fields are target host address, host’s port, format to be used and transaction header.
Configuring a host address and port used simply tells Source module where to send transactions, while transaction format says which format will be used for sending. Very important is setting the Transaction header field. Each payment transaction is framed within a TCP frame, where payment system needs to also know whether the message was delivered completely or split into several frames, during it’s path to the host system. Transaction header says payment message total length, creating a simple validation option, but also adding several bytes of information in front of the message. Check your target system’s configuration and setup correct header first or messages generated won’t be recognized. Usual header has 2B with those bytes being excluded or included into message total length. Our selection says “2B-length excluded”, so the header length value will carry just message length only. Don’t forget to hit the “Save” button to store configuration in database.
How we need to have a look at format settings. Current selection says that we’ll be using ISO8583:1987 format for processing. Unfolding formats list-box would reveal all available formats, given by license provided, but now we need to check formats configuration to understand technique for message construction and transaction templates. You can see ISO8583:1987 configuration screen on the picture following. This screen differs based on transaction format and each screen is described in detail in our User Guide. We’ll focus at Profile field and Active checkbox now.
Profile list-box contains a list of all configured transactions. These can be managed with buttons located on the right side, allowing user to change, copy or delete those. Very important is the Active check-box, which flags a message profile to be used for testing. Note that active message flag might be overridden from a test script as all other fields in the message, but test script testing mode will be covered in a different article.
Now when we did check transaction properties, we also need to check transaction source device, in this case a terminal. On the screenshot below you can see the terminal’s configuration screen. This screen can be opened through the navigation screen – Terminals menu option. As per sources you can see list of available terminals, where active terminals are marked with leading star ‘*’. Note that multiple terminals can be active in parallel, but in our current testing mode, just the first one will be used. Important settings on the terminal screen says are how many transactions will be send and which card will be used for testing. Selecting a random cards option in the cards list will randomly select a card from all active cards configured and a choice will be different for each transaction. Terminal’s configuration can be saved, cloned and deleted with right side buttons again.
Last setting I want to cover in this tutorial is the card management. Typical card settings can be seen on the picture below. It is a best practice to fill in as much information you know to prevent message corruption, when you will use an empty field (left empty in transaction template as well as in card’s or terminal’s configuration).
Having basic configuration done, we’ll get back to the Source control screen (see screenshot below). Here you can see some limited configuration options and brief overview of the test prepared. As I did start a BP-Host service in the background, running it locally on port 7002, the test ended up successfully and reporting some statistics into the output screen. Valuable information is that all transactions were successfully responded and whole test took about 7ms.
Based on the test undertaken, we can now go to the trace log screen for terminal 80000001. There you can see and analyze carried test’s output. Note that trace log has all message fields parsed, binary message part and all comments and issues reported by message parser as seen on picture below.
In this tutorial, we did go through major configuration screens needed for basic test run and covered most critical parts of their setting. This article also provided information on how to start, stop and read test results plus gave some overview on BP-Sim management console usage.