I believe every GXS AI map developer knows how hard it might be to debug maps. I’m using SEND_SMSG function when I need to debug a piece of code
First of all, I’m using .bat files to run my maps
otrun -at %MAP_NAME%S.att -cs %OT_QUEUEID% -DLOCALE="English_UnitedStates.Latin1@Binary" -DINPUT_FILE=%BASE_PATH%__in.txt -DOUTPUT_FILE=%BASE_PATH%__out.txt -tl 1023 -lg _log.txt -I
this key “-lg _log.txt” tells the translator to use _log.txt for the translation session output. So, every time I’m using SEND_SMSG it writes it’s 1+ params into _log.txt. For example:
SEND_SMSG(1, STRCAT("GID_21_BALQTE_BSD_02_02_2002: ", VAR->GID_21_BALQTE_BSD_02_02_2002_T))
And in _log.txt:
Session  Started: at: Sat Jul 25 09:03:04 2012
Session  ended: err: 0 at: Sat Jul 25 09:03:04 2012
…As always, just an idea 🙂
As you probably know, often GXS AI developer use 3rd party editors when working with the models (instead of Workbench). My colleagues use Notepad++ with a “plugin” (User Defined Language) developed by Igor Nechaev:
it highlights used constructions, allows to to collapse/expand blocks of code, helps you to comment/uncomment blocks of code and so on.
Here is the code of this “plugin” (User Defined Language):
We’ve just found that NUMTRIM function works in a different way on different environments.
On our local servers (4.1, 5.0 and 5.2 on Windows) NUMTRIM(“”, 0) returns 0, but on another machine (I believe on Unix) it returns garbage (and no error message)
As I wrote before, I’m often trying to use/create some tools/scripts which helps me to do different things – build the test data, compare outputs or check the models. For example when I was working a lot with GXS AI I created a tool which showed me the list of the variables and arrays used in the maps + some “assumptions” (for example, if a variable is not used). Also, it generated a code to check all the arrays (they all should be empty at the end of the translation). It helped us to keep the maps clean. There is no Print to File option in GXS AI Workbench (like Sterling’s MapEditor has) so often it was hard to see the whole picture, especially when the map contained hundreds or thousands lines.
Such tool would also help you to migrate maps from GXS AI to Sterling GIS/SI (or another EAI) and back.
Here are some screenshots just to give you an idea:
Variables (and Arrays)
In this lesson we’ll see how to use variables and the difference between variables and arrays.
It’s time to start working with more complex structures which are more similar to the “live” documents. We’ll be using our map “example02” we created on previous step as the base. Let’s change it.
First of all, we need to change the structures of both source and target documents. In the real life documents usually contain three main parts (blocks of data):
- Header. This block usually contains the document number/date, addresses and so on – the common information.
- Details. Usually there some kind of a repeatable data (Line Items and their IDs, names, quantity, price and so on)
- Summary section. This block contains all the total amounts, taxes/fees, total quantities and so forth. This section is very similar to the Header section, but often it is placed at the end of the document to emphasize its “summary” role (like you can see in the paper documents).
Arrays of data
In this lesson I’ll introduce you a concept of arrays in GXS AI.
Our first map we created on previous lesson is pretty simple. Both source and target have almost the same structure, only one type of records and a few fields. In real life such maps are very seldom. So, we need to gradually work on more and more complicated maps. Let’s get started!
If GXS AI WB/TG (at least 4*) don’t work with your version of Java (you have 1.4 instead of 1.5), try to open
JVM_VERSION_MAJOR_REQUIRED = 1.5
JVM_VERSION_MINOR_REQUIRED = X_XX
JVM_VERSION_MAJOR_REQUIRED = 1.4
JVM_VERSION_MINOR_REQUIRED = X_XX
Creating the simple links
Now, when both source and target models are ready, we can continue.
We’ll start with the “simple links” – very, well, primitive 🙂 technique, which “explains” to the translator how to create the target document using the source data. Usually, the simple links are used in very simple cases – when the target structure is similar to the source.
Our example is pretty obvious – the data from Line Item ID, Quantity, Unit Price and Exp. Date from the source document go into appropriate fields of the target one. Both structures are almost the same – repeatable records of the same type. So, the simplest solution here is to use the simple links.
To create the simple rules, open the map, select the first field for linking – LineItemID, leftclick on it and holding the button move the pointer to the target LineItemID (drag and drop). You’ll see a blue line connecting both elements (see below). This line means that the data from the source’s LineItemID will go to the target’s LineItemID.