BIC-ISO - Anybody interfacing to BASE24 from jPos?

[Mark Salter]

Hi all.

I would like to ask if anyone has successfully exchanged transaction
with a BASE24 system using the ACI BIC-ISO interface at all?

I'm wondering if you also use our GenericPackager set-up?

--
Mark

[Victor Salaman]

Mark, yes, a long time ago... :)

[Mark Salter]

Victor Salaman wrote:
> Mark, yes, a long time ago... :)

Any chance you still have the packager config available at all?

--
Mark

[Victor Salaman]

Hi Mark:

You can use the same base24.xml used in the distribution, as BIC ISO uses the same packaging as the base24 external message:

     <channel
          name="XXX-channel"
          packager="org.jpos.iso.packager.GenericPackager"
          header="ISO026000050"
          class="org.jpos.iso.channel.BASE24TCPChannel"
          logger="REMOTE" realm="channel.ath">

        <property name="timeout" value="800000"/>
        <property name="host" value="${xxxHost}"/>
        <property name="port" value="${xxxPort}"/>
        <property name="packager-config" value="cfg/packager/xxx.xml" />
    </channel>

What will actually be "different" is your channel configuration, as the header might be longer, and this is site-configuration dependent (as defined in the host's HCF for that DPC). Following is table of breakdown of the message. As you can see in the example above "ISO026000050" complies with the minimum header requirement, but you should check with your host people to provide you with header elements they're expecting.  

+--------------------------------------------------------+
|           BASE24 External Message Components           |
+-----------------------------------+-----------+--------+
|               Component           |   Length  | Reqrd? |
+-----------------------------------+-----------+--------+
| Data prefix characters            | 0-9 bytes |  No    |
| IMS/CICS transaction codes        | 0-9 bytes |  No    |
| SOH ('ISO' Literal)               |  3 bytes  |  Yes   |
| BASE24 header                     |  9 bytes  |  Yes   |
| MTI                               |  4 bytes  |  Yes   |
| Primary Bitmap                    | 16 bytes  |  Yes   |   
| Data Elements                     | variable  |  N/A   |
+--------------------------------------------------------+
 
/V

[demsey]

Hi

base24.xml from jPos distro has some mistake in 64 or 128 field
definition (MAC fields)
You maight consider use also org.jpos.iso.channel.PostChannel (It's
seem
to me that it is better supported by Base24)

[Victor Salaman]

Hi Demsey:

I'll attempt to ignore what you just typed :)

As per the ACI BASE24-{atm,pos,telebanking,teller} documentation I have in my hands, the packager in the distribution matches both field 64 and 128. What the distribution base24.xml lacks is the definition of some sub-field-packagers,  since the contents of some of those the fields can change between different ACI products. You're supposed to take the distribution base24.xml, compare to your spec and use as a base for your implementation.

Postilion is another product altogether, so if it seems to you that the PostChannel channel is "better supported by BASE24", then I'd like to try the same illegal drugs you're taking :)

Peace and out,

/V

[David Bergert]

you mean:

/**
* ISO 8583 v1987 Packager for Postilion
*
* @author Victor A. Salaman <sal...@teknos.com>
* @version Id: PostPackager.java,v 1.9 1999/09/17 12:08:02 salaman Exp
* @see ISOPackager
* @see ISOBasePackager
* @see ISOComponent
*/

public class PostPackager extends ISOBasePackager {

instead of PostChannel right ?


David Bergert, CISSP, CISA, CPISM/A
www.paymentsystemsblog.com

[demsey]

Victor - you have right, but I know what is Postilion


I only suggested that instead org.jpos.iso.channel.BASE24TCPChannel
you may try to use org.jpos.iso.channel.PostChannel.
In my case BASE24 BIC-ISO interface understand BASE24TCPChannel (quite
obvious) but also PostChannel (quite strange)
(One of cooperative companies work only on PostChanell, thus i decided
to switch all BASE24TCPChannel to PostChannel - for unification)


<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE isopackager SYSTEM "genericpackager.dtd">

<!-- BASE24 field descriptions for GenericPackager -->

<isopackager>
...
<isofield
id="64"
length="16"
name="MESSAGE AUTHENTICATION CODE FIELD"
class="org.jpos.iso.IFA_BINARY"/>
...
<isofield
id="128"
length="16"
name="MAC 2"
class="org.jpos.iso.IFA_NUMERIC"/>
</isopackager>

Field 64 is as IFA_BINARY but 128 as IFA_NUMERIC - according to my
documentation one of them is wrong but now i don't remember which one

On 14 Paź, 21:09, David Bergert <dbergert...@gmail.com> wrote:
> you mean:
>
> /**
>   * ISO 8583 v1987 Packager for Postilion
>   *

>   * @author Victor A. Salaman <sala...@teknos.com>

[Alejandro Revilla]

Field 64 is as IFA_BINARY but 128 as IFA_NUMERIC - according to my
documentation one of them is wrong but now i don't remember which one

I believe field 128 is wrong; just fixed it.
 

[demsey]

Victor - again you have right
I recheck my documentation
P-64 Primary Message Authentication Code
Format: AN 16
S-128 Secondary Message Authentication Code
Format: N 16
So - base24.xml is ok
It seems that cooperative company send for us both fields as
IFA_NUMERIC (or IFA_BINARY i can chek it tomorrow when i arrive to my
company)

Thing about channel. Please treat it as interesting detail. I don't
now that is working in all cases;)

[Victor Salaman]

Hi Robert:

I have three sets of documentation: 5.0 11/95,5.0 02/96 and 6.0 ... Interestingly enough there appear to be a mistake in the 11/95 5.0 docs, as what you mention is there... But in newer docs, both field 64 and 128 are "AN", so the commit Alejandro just made would make the packager consistent with newer docs. Thanks for the input.

Cheers,

/V 

[Alejandro Revilla]

As a matter of fact, I've been doing some tests and I think the commit was wrong, and the packager was wrong too. If we use IFA_BINARY we need to set the length down to 8 as it will emit 16 bytes when we use IFA_BINARY.

I've tried the following script:

import org.jpos.iso.*;
import org.jpos.iso.packager.*;
ISOMsg m = new ISOMsg("0800");
m.set (64,  ISOUtil.hex2byte ("0011223344556677"));
m.set (128, ISOUtil.hex2byte ("7766554433221100"));
ISOPackager p= new GenericPackager("base24.xml");
m.setPackager (p);         
print (ISOUtil.hexdump (m.pack()));

that produces

0000  30 38 30 30 38 30 30 30  30 30 30 30 30 30 30 30  0800800000000000
0010  30 30 30 31 30 30 30 30  30 30 30 30 30 30 30 30  0001000000000000
0020  30 30 30 31 30 30 31 31  32 32 33 33 34 34 35 35  0001001122334455
0030  36 36 37 37 37 37 36 36  35 35 34 34 33 33 32 32  6677776655443322
0040  31 31 30 30                                       1100

That's fixed in r5199;

I believe most people using this packager is probably not using MAC, that's why this old config bug is there.

[Victor Salaman]

Exactly why this is a community project :)

There could be errors in the packager in fields which are rarely used by our community, in this case, we should verify other instances of this, such as field 96, which is also defined with a length of 16 for consistency, and here's the explanation:

------------------------------------------
S-96: Message Security Code
Format:    AN 16
Used By:    Not used by BASE24

The ISO standard format for the Message Security Code (S-96) data element is B 64. However, BASE24 assigns a format of AN 16 because binary fields are not supported in the BASE24 external message. This difference in formats should not have any effect since BASE24 does not use this data element.
------------------------------------------

In my opinion we should make a special field for this type of case, since it's one of those times where the spec won't match the packager (spec shows "display size" vs. our packager uses "storage size").

/V

[Alejandro Revilla]

Good point Victor.  Fixed that one too (r2800)

In my opinion we should make a special field for this type of case, since it's one of those times where the spec won't match the packager (spec shows "display size" vs. our packager uses "storage size").

Not sure if we need a new FieldPackager or just properly document the fact that display is different than storage size...

[Victor Salaman]

IMHO It's ok the way it is. I just mentioned it because as you know most people don't read docs :->

/V

[mwyc...@gmail.com]

Hi Mark,

The one I have exchanged transactions with was an ACI BASE24-es ISO 93
Host,
and I used <!-- ISO 8583:1993 (ASCII) field descriptions for
GenericPackager -->
as the packager.