ISO 8583 Setup
Could you provide some detailed instructions with screen shots and context around setting up an ISO 8583 listener in Virtualize and then testing it with SOAtest?
Thanks,
JT
Comments
-
It would also be very helpful to have the same thing for a Kafka Listener. I have read the Parasoft docs on both but it is not all that intuitive to me. Thanks.
JT
0 -
Concerning ISO 8583, I've provided various feedback about this in the past. To help anyone looking on the forum, I'm taking this opportunity to collect past feedback and paste it here:
Concerning ISO 8583 message consumption/generation (XML conversion):
The ISO 8583 Extension is based on jPOS, a popular open source implementation of ISO 8583. The common practice is to define a Generic Packager XML file that describes the fields in your message. jPOS provides some examples which can be used as reference: https://github.com/jpos/jPOS/tree/master/jpos/src/dist/cfg/packager
In practice, users need to define their own Generic Packager XML based on the specific messages they need to generate or consume. Typically, the "spec" is an organization's own internal document or pdf that defines their message fields, which they would need to translate into their own Generic Packager XML file that is understood by jPOS.
Concerning ISO 8583 transport/listener channels:
The ISO 8583 Extension provides support for jPOS Channels for sending and/or receiving messages over TCP/IP. By default, jPOS Channels create a plain Java Socket. The ISO 8583 Extension lets you configure the java class name of the Channel which can come from a user-provided jar.
Concerning ISO 8583 message headers:
The "packager" (in jPOS) can be configured to handle the message header all on its own. In this situation, your GenericPackager XML file would have a "headerLength" attribute. The header length is the number of bytes that make up the header, which is not necessarily the same as the number of characters in the XML representation of the header. In the XML version of the message, you would define the header value in a "header" element with an optional encoding="ascii" attribute depending if the value is to be interpreted as as-is (ASCII text) or as hexidecimal (binary) when converting the XML to the native binary representation. This type of configuration is very flexible, especially for Message Responders, because it allows you to configure the header directly in the XML version of the outgoing response, or correlate on the value of the "header" element in the incoming request. The header length configuration in the message listener does not get used in this situation because it is controlled by the packager and you will see a message printed to the console about this if you try defining a header length there that is different than the one defined in the packager. For clients, you will also see the message header as part of the message body in the traffic viewer this way.
I have also seen header fields described no different than body fields, where there was no strong delineation between header and body, just some fields coming before other fields. So, this may also be something to consider depending on the user's definition of "header", as opposed to what jPOS or soavirt consider "header". A similar possibility is to build the header with a separate XML Convertor tool with a different GenericPackager XML file that just describes fields for the header then parameterize the "header" element in another client.
1 -
Could you provide some detailed instructions with screen shots and context around setting up an ISO 8583 listener in Virtualize and then testing it with SOAtest?
How to configure things is very specific to an organization, like what packager XML file needs to be configured. However, a contrived example isn't terribly difficult. I could put together something and attach it here later.
1 -
It would also be very helpful to have the same thing for a Kafka Listener
What are you sending over Kafka? ISO 8583 messages? Or Apache Avro messages?
1 -
8583
0 -
It sounds like you would be using the ISO 8583 message format with the Kafka Listener and Kafka Transport. You wouldn't be using the ISO 8583 transport/listener because that is only used if doing messaging with a jPOS Channel.
1 -
Thanks for that. In addition to 8583, I think there will be scores of other use cases here at the bank for Kafka. Promise I'll put any knowledge you can share to good use. JT
0 -
We're just starting to mingle Parasoft-aware teams with ISO 8583-aware teams. Being a part of the former I am hoping to gain as much knowledge as I can on how to support the latter. I have a solid understanding of JMS/MQ, but I am not familiar with configuring a Parasoft component to interact with Kafka, etc. I think once we get something off the ground it is going to be huge.
0 -
Magic. Just ask JD. LOL
0