Posted on 3rd Oct 2018 1949 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).
Run the neaPay ISO8583 simulator 8442 views
Log Files in BASE24 classic 3270 views
BASE24 documentation to read 2899 views
BASE24 classic vs BASE24-eps 2872 views
BASE24 classic interview questions 2821 views
BASE24 classic screens examples explained 2306 views
Enabling traces in the payments simulator 2026 views
EMV explained for programmers 1871 views
BASE24-eps interview questions 1837 views
Cards and Banks Training 1775 views
Working with Base24-eps vs BASE24 Classic 1037 views
BASE24 classic routing in IDF 996 views
First steps with BASE24 Classic 812 views
Ready to start your next project with us? Give us a call or send us an email and we will get back to you as soon as possible!