NDC+ Protocol too complex for FSDMsg

[Jonathan]

Hi,
I've been trying to define my message schema for NDC+ Transaction
Request messages. This is a particularly complex format, and I don't
think that FSDMsg, as it currently stands, can support this. The main
problems are:
1. Fields are only included depending on a configuration parameter.
for example, the Message Authentication Code Data field (the last one
in the message) only appears in the message if the Data Security
feature is selected.
Note: if the flag is not set, then the fields and any field separators
do not appear at all. I can envisage xml like:
<group condition="MAC-Security">
<field id="MAC Data" length="8" type="A"/>
</group>
The packager would need access to a Set<String> containing features
that are enabled for this message.

2. Repeating fields, or repeating groups of fields. Sometimes, these
are marked with an ID field, and sometimes, the repeating fields end
with a group separator, or some other marker. I have no idea how this
should be designed.

Packing the message with these added features is not much of a
problem, however, unpacking is! Currently, the unpacker never has to
look ahead. Yes the key fields tell it where next to go, but it never
has to do any backtracking. I want to avoid this if possible.

Firstly, am I mad, enhancing FSDMsg? I feel it is going to grow into
something like the ISO 8583 packagers and fields, with its nested
packagers, and message bitmaps.

Secondly, is there an alternative solution that I am missing? Yes, I
am aware that the exact message format should be documented somewhere
by the bank, but that does not apply in my case, as I'm writing an ATM
controller, and it has to be flexible in the schemas it handles.

Thanks,
Jonathan

[AAO]

"Firstly, am I mad, enhancing FSDMsg?"

To do NDC+?  Quite.

You need a special message class to handle those beasts.

Andy

[Jonathan]

Andy,
So, it seems it makes sense to use FSDMsg to generate terminal
commands, and maybe even Transaction Replies, but we will have to
write our own Msg class for recognizing and parsing Transaction
Requests. That's a pity, but I guess it's better than nothing.

Thanks for the advice,
Jonathan, Trainee Lion Tamer

[Alejandro Revilla]

1. Fields are only included depending on a configuration parameter.
for example, the Message Authentication Code Data field (the last one
in the message) only appears in the message if the Data Security
feature is selected.
Note: if the flag is not set, then the fields and any field separators
do not appear at all. I can envisage xml like:
<group condition="MAC-Security">
   <field id="MAC Data" length="8" type="A"/>
</group>
The packager would need  access to a Set<String> containing features
that are enabled for this message.

Can't you just select a different schema when the MAC-Security feature is enabled?

In some of my FSDMsg use cases, I use XML entities to expand different groups, i.e:

<!DOCTYPE schema SYSTEM "groups.dtd">

my groups.dtd look like this:

<!ENTITY group-1 SYSTEM "visak-group-1.xml">
<!ENTITY group-1-swiped SYSTEM "visak-group-1-swiped.xml">
<!ENTITY group-1-manual SYSTEM "visak-group-1-manual.xml">
<!ENTITY group-2 SYSTEM "visak-group-2.xml">
<!ENTITY group-3 SYSTEM "visak-group-3.xml">
<!ENTITY group-1-response SYSTEM "visak-group-1-response.xml">

Then, I can define different message types including different groups, i.e:

 ?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE schema SYSTEM "groups.dtd">

<schema id="K0-">
 &group-1;
 &group-3;
</schema>

I guess you could define a group like this for your MAC related fields and have two different outter schemas.


 

2. Repeating fields, or repeating groups of fields. Sometimes, these
are marked with an ID field, and sometimes, the repeating fields end
with a group separator, or some other marker. I have no idea how this
should be designed.

Lovely... that probably requires handling nested FSDMsgs and unpacking on the fly using the unpack (InputStream is). Not nice.

If you hit a wall and conclude that FSDMsg can't help here, I think you could consider using a lexical analyzer/parser generator.

[Jonathan]

Alejandro,
buried deep in my brain was that XML Entity trick. Neat.

Yes I could use different schemas, but there are many configuration
parameters (at least 20), so 2^20 schemas are a few too many for me!
Of course, as we control the configurations, maybe I can decide we
will only support one particular configuration. That might be the way
to go.

As for nested messages, do we not have those purring like kittens in
the ISOPackager code?

I have plenty of food for thought now,
thanks guys,
Jonathan

[Alejandro Revilla]

Victor recently added a freemarker based decorator for Q2's QBean descriptors, I guess you could use something like that to dynamically decorate the FSDMsg XML configurations on-the-fly at load time, based on your runtime configuration parameters.

[willard kurisa]

Hello Jonathan?

Did you manage to get this working?

Will