Welcome to the new Parasoft forums! We hope you will enjoy the site and try out some of the new features, like sharing an idea you may have for one of our products or following a category.

ISO 8583 Setup

jefftuckerbofa
jefftuckerbofa Posts: 234 ✭
in Virtualize

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

Tagged:

Comments

  • jefftuckerbofa
    jefftuckerbofa Posts: 234 ✭

    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

  • benken_parasoft
    benken_parasoft Posts: 1,309 ✭✭✭
    edited October 2023

    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.

  • benken_parasoft
    benken_parasoft Posts: 1,309 ✭✭✭

    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.

  • benken_parasoft
    benken_parasoft Posts: 1,309 ✭✭✭
    edited October 2023

    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?

  • jefftuckerbofa
    jefftuckerbofa Posts: 234 ✭

    8583

  • benken_parasoft
    benken_parasoft Posts: 1,309 ✭✭✭

    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.

  • jefftuckerbofa
    jefftuckerbofa Posts: 234 ✭

    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

  • jefftuckerbofa
    jefftuckerbofa Posts: 234 ✭

    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.

  • jefftuckerbofa
    jefftuckerbofa Posts: 234 ✭

    Magic. Just ask JD. LOL

Categories

Tagged