4.1.6. Debug your channels
This page is a bit more technical, and should not be read before you are comfortable with the Babelway concepts. But when you will start building more complex channels, finding easily where you could have a problem in your configuration is very important. This page explains how to exploit all the information that is stored about your messages.
Messages
To check or debug a channel, the starting point will almost always be a message that went through your channel. It can be a test message or a real message, but in all cases, many details will be available in the MessageDetail screen.
Step files
A very important question when you debug a message that did not produce the expected output can be to know at which step things went not as expected, and therefore in which step I should go and fix the error.
To help answer these questions, Babelway stores the file that is being processed at every step of its transformation from the input message to the output message. This can be found in the Step files section of the Message detail. By looking at these files, you can find until when things went perfectly, and at which step things went wrong.
But interpreting these files can require a bit of additional information about how Babelway works internally, and especially the fact that Babelway will only execute transformation on an internal XML representation of the messages.
The steps are :
- The gateway IN just cares about the reception of the message from your partner, and don't make any change to it. If the Step file Message IN received is not as expected, the problem comes from your partner, or from the communication protocol. If it is right, you know that the reception is ok, and the the problems happens in a later phase.
- The MessageDefinition IN will analyze the input file, and convert it to the Babelway XML internal representation for this message type. You know that this phase is ok if you can see all the fields correctly extracted in the Message IN after transformation to XML step. If not, the problem can only come from the configuration of your MessageDefinition.
- The transformation will convert the Xml representation of the message IN to the xml representation of the message OUT, applying all the rules that you have defined in the transformation. The problem comes from this step if the Message IN after transformation to XML step was correct, but the Message after transformation step file is not (you don't have the right value calculated for every field).
- The MessageDefinition OUT will convert the xml representation of the message OUT and generate the related file in the expected format. The problem comes from this phase if Message after transformation step file was right and Message OUT after transformation from XML step file is not.
- The gateway OUT doesn't change the message OUT. You should not see any step file for its execution. The problem can only come from this phase if your partner shows that the file he ahs received is not the one mentioned as Message OUT.
Let's illustrate this by looking carefully at every step file in the below example, where we received a pdf, and converted it to a csv. We can see the 4 files as expected :
- Message IN received is the source pdf, and we can open it without any problem.
- Message IN after transformation to XML shows that all the fields that we wanted have been correctly extracted.
- Message after transformation shows that all of our calculations have been applied correctly (here mostly the addition of the Density field).
- Message OUT after transformation from XML shows that the output csv is exactly as expected (right delimiter, ...).
Context IN and context OUT
When debugging the processing of a message, the content of the file step after step is very important, but the whole info about the message is not only this content. It can also be about all the additonial info that are attached to the message, mostly metadata. You can check the values for all of these fields by looking at the Other files : Context In and Context out.
Context In contains all the metadata of the message when the message was created in the platform. It is very useful to check some metadata coming from the communication protocol, or from a prior channel.
Context out contains all the metadata of the message when the message was finished being processed. It is mostly useful to check whatever happened during the message execution in this channel.