Posted on 3rd Oct 2018 6788 views
Hello and welcome to this brief guide about the standard run modes available to the neaPay ISO8583 Acquirer simulator.
4 modes are available to the user out of the box:
In detail, about each one.
Is the most commonly used mode for running transactions, by selecting them from the list and running that test case only. This is the most used because it is designed for the test phase, or test cases preparation phase.
When you select this mode, the simulator will run the test case identified by: Scenario, Number, Description.
When you click the Send button, the simulator will take the line you selected from the Transactions List and match it against the Acquirer spreadsheet (exported csv file), and then will run the first test case that matches.
It is important that each test case configured in the Acquirer spreadsheet has a unique combination of Scenario, Number, Description. If you have several rows with the same key, it will run the first combination found.
This run mode is ideal for running tests for a very specific functionality, like a suite of EMV tests that tests each tag, or for MPOS - specific certification, or just a simplified sub-set or regression.
In order to run in this mode, just select a transaction from the Scenario you want to run, from the list of transactions UI.
This mode runs all test cases that have the same scenario number/ID as the selected transaction. If you have all test cases with the same scenario number/ID, then the simulator will run them all.
This mode is used when running automated regressions, it runs all the transactions from the list.
A regression pack for an ISO8583 implementation is usually estimated to have 500-1000 test cases that run one after another and test various functionalities, like amounts, accounts, limits, pin tries and so on.
Setting up a good regression pack may cost an initial investment, but it allows you to run an automatic regression every time you make a change, in less than 15 min.
This mode is used to run load tests at a steady, fixed and measured TPS (Transactions per Second) rate.
The simulator switches to core-only mode, like a Host, ignores human interaction, like a host, and focuses on running transactions as fast as possible. While doing so, it outputs the amount of time it has to spare in a second after sending the specified number of transactions.
In simple words, if you want to run 10 transactions per second, you set the TPS rate to 10, and the neaPay Core will send 10 cached transactions, measure how much time it took, for example 0.05 seconds, write to console the remaining time in a second, in this case 0.95 seconds, so you know how much more load you can do with your device. Up to around 1000 transactions per second is the tested limit for a low-end laptop. A good server can do many thousands.
Data for running the load test must be cached before. This is enabled in the Acquirer script, and what it does is store transactions that you are running manually in the RunOne or one of the other modes (if enabled).
ISO8583 Message Types for Transaction Processing
Run the neaPay ISO8583 simulator
Cards and Banks Training
Log Files in BASE24 classic
BASE24 classic vs BASE24-eps
BASE24 documentation to read
BASE24 classic interview questions
EMV explained for programmers
Enabling traces in the payments simulator
BASE24 classic screens examples explained
BASE24-eps interview questions
PCI compliant with neapay switch
First steps with BASE24 Classic
Convert ISO8583 to JSON XML SQL
ISO8583 Interface Handler
Convert ISO20022 to ISO8583 ...
Build ISO8583 from scratch
ISO8583 Router by criteria
Authorize cards and ledger
Acquiring host from devices
Generate and issue cards
ISO8583 generic simulator
ISO20022 generic simulator
POS protocols simulator
Web API tester Performance