Share this link

    Home / Tradeshift Documentation / Tradeshift Partner Apps / Babelway / Chapter 3. Monitoring

    3.1.2. Message details

    880 0 Created on 2020-09-21 13:50:55; Last updated on 2022-07-01 13:01:13

    Message Details screen shows you all the details about the processing of a message by Babelway system. It also allows you to make all necessary actions on this message.

    You can access it by clicking on its line in the messages list screen, or you can find a specific message by searching for it with a reference like file name, date, etc.

    First you will get Short Message Details screen on the right as seen below : 

    

    Short Message Details Screen

    And when click on View full details you will get the full message details as seen below.

    

    

    Message Details Screen

    The following information can be available on a message:

    • Status: The status of the message processing. The possible statuses are: 
    • Processing: Message is being processed by Babelway. 
    • Paused: Message processing was temporarily stopped (because human validation has been requested, because it can only be delivered in specific time frames)
    • In delivery: Message is being transferred to the target system. This status differs from "In progress" in the sense that the output message is completely generated and available via the interface, but communication of the message to the target system is not yet terminated. The reasons for this delay in the communication can be multiple: We wait for the file being downloaded, or we wait for an acknowledgment, or the target system was unavailable and we will retry later.
    • Success: Message processing is completely finished and action done as requested. 
    • Error: When there was an error in any step of the processing. 

    Here are some examples of errors: 

    1. The received file did not pass the input validations. 
    2. The generation of the output file completed successfully, the file was made available for download on Babelway FTP server, but was never downloaded (after X days). This is an error because we know that the file was not received by the end user. 
    3. The generation of the output file was completed successfully and the file had to be sent by email to 2 recipients. "One of the deliveries succeeded (and the user) correctly received the message, while the other delivery failed."
    4. The generation of the output file completed successfully and was correctly uploaded to the target system, but we did not receive an expected acknowledgement (or it was not correct). 
    5. The processing crashed.  

    The precise description of the error will always be present in the field "Error description" Error (closed): This status never indicates an automatic action by the system, it's a subsequent status after you have analyze and fix the error. 

    • Error (closed): This status never indicates an automatic action by the system, it's a subsequent status after you have analyze and fix the error. 
    • Date in:  The date and time when the message was received by Babelway. 
    • Date out: The date and time when the processing of the message was completely finished (even if complete processing of the message implied waiting for an acknowledgement from the external system, waiting for download by the client, making retries, etc.). 
    • Processing complete: The date and time when the Babelway processing of the message was finished. This is the moment when the message out is made available to the target system.  This time will differ from "Date out" when the delivery of the file implies waiting for the external target system (ex: waiting for an acknowledgement, waiting for a download, or waiting for the external system availability). "Processing complete" doesn't include this delay while "Date out" includes this delay. 
    • Keep until: The date and time until which the message will be kept in the Babelway system. You can change this setting for your whole environment or by channel. 
    • Message In:  Incoming file, as received by the source external system. Click on the file name to open it.  Note: If there is a file name provided in the "Message In" or "Message Out" which contain ~ tilde character, All browser based on Chromium will replace the ~ tilde character by the _ underscore character when you try to download the file from the Babelway interface, For more details you can check this link 
    • Message Out: Outgoing file, as sent to the target external system. In case of processing error, this file may be unavailable if the messaging engine was unable to generate it. Click on the file name to open it.  Note: If there is a file name provided in the "Message In" or "Message Out" which contain ~ tilde character, All browser based on Chromium will replace the ~ tilde character by the _ underscore character when you try to download the file from the Babelway interface, For more details you can check this link https://bugs.chromium.org/p/chromium/issues/detail?id=479419
    • Error description: When the message couldn't be processed, a text that describes the error's reason. 
    • Type: Message type, can be either Test or Regular
    • Test Status:  Only for test messages. The test status can be either Test failed, Waiting result or Test successful. It should be differentiated from the Status field, that tells if the message has been processed without errors. When you make a test case, you can add complementary assertions on the result of the processed message. This will cause the test to be considered as 'failed' if not fulfilled. 
    • Channel: The channel that processed the message.
    • Gateway In: Incoming gateway used to receive the input file. 
    • Gateway Out: Outgoing gateway used to process the output file. 
    • Key: A UUID (universal unique identifier) that uniquely identifies a Message. 
    • Reference: Message reference or file name. You can choose this reference. 
    • Gateway in message key: Specific communication-level identifier from the gateway in. 
    • Gateway in message status: Specific communication-level information from the gateway in, like related id's or addressing information of partner systems. 
    • Gateway out message key: Specific communication-level identifier from the gateway out. 
    • Gateway out message status: Specific communication-level information from the gateway out, like related id's or addressing information of partner systems, info about acknowledgments, retries.
    • Size of incoming message: Incoming message size (in bytes). 
    • Size of outgoing message: Outgoing message size (in bytes). 
    • User comment: Free text allowing the user to comment on a message. It can be changed anytime from the SelfService application as well as during in the processing of any message. 
    Note: You can populate the user_comment system metadata in the transformation using setMetadata('user_comment', 'Replace this text with the text you want to use as a user comment or you can map it from a field from the Message In'), as shown below.

    

    Populate the user_comment system metadata in the transformation using static text

    

    Populate the user_comment system metadata in the transformation from a field from the Message In

    The section Internal files also gives you access to internal data about the processing of the message. This information can be useful to investigate some problems, or to understand the behavior of the system. Two categories of internal files exist: The step files and the other files.

    The step files represent the evolution of the message content from the message IN to the message OUT. After each modification of the message's content, a new step file is created. Here is the complete list of possible types of step files:

    • Message IN received: The message IN as it was at the start of the processing (after reception by the gateway IN). 
    • Message IN after unwrapping (Deprecated): The message IN after the deprecated unwrapping extra-processing. 
    • Message IN after S/MIME unwrapping: The message IN after the S/MIME unwrapping extra-processing. 
    • Message IN after PGP unwrapping: The message IN after the PGP unwrapping extra-processing. 
    • Message IN after ZIP:  The message IN after the ZIP unwrapping extra-processing. 
    • Message IN after PDF unwrapping: The message IN after the PDF unwrapping extra-processing.
    • Message IN after regular expression transformation: The message IN after the regular expression based extra-processing. 
    • Message IN after Serving XML transformation: The message IN after the Serving XML based extra-processing.
    • Message IN after transformation to XML: The message IN after its conversion to an internal XML representation. 
    • Message IN after XSLT transformation: The XML message IN after the XSLT based extra-processing. 
    • Message after transformation:  The XML message after its transformation. 
    • Message OUT after XSLT transformation: The XML message OUT after the XSLT based extra-processing. 
    • Message OUT after transformation from XML: The message OUT after its conversion from the internal XML representation. 
    • Message OUT after Serving XML transformation: The message OUT after the Serving XML based extra-processing.
    • Message OUT after regular expression transformation: The message OUT after the regular expression based extra-processing. 
    • Message OUT after line delimiter transformation: The message OUT after the line delimiter transformation extra-processing. 
    • Message OUT after PDF wrapping: The message OUT after the PDF wrapping extra-processing. 
    • Message OUT after ZIP wrapping: The message OUT after the ZIP wrapping extra-processing. 
    • Message OUT after PGP wrapping: The message OUT after the PGP wrapping extra-processing. 
    • Message OUT after S/MIME wrapping: The message OUT after the S/MIME wrapping extra-processing. 
    The other files represent the additional information (other than the content) produced during the message processing. Here is the complete list of possible types of other files:
    • Context in: Full context of execution of the message, as it was at the start of the processing (after reception by the gateway IN).  
    • Context out: Full context of execution of the message, as it was at the end of the processing. 
    • Context: Additional list of properties and log of processes applied during message processing.
    • Message Delivery Notification In (MDN In): The Message Delivery Notification (MDN) that was sent to the caller, to prove that Babelway has received the message. 
    • Message Delivery Notification Out (MDN Out): The Message Delivery Notification (MDN Out) that was received from the receiver of the message, to prove that Babelway has correctly submitted the message to its destination. 
    • Documents In: When a document extractor is used on MessageDefinition IN, the extracted documents. 
    • Documents Out:  When a document extractor is used on MessageDefinition OUT, the extracted documents. 
    • Invoices In: When a document extractor is used on MessageDefinition IN, the extracted invoices. 
    • Invoices Out: When a document extractor is used on MessageDefinition OUT, the extracted invoices. 
    • Orders In: When a document extractor is used on MessageDefinition IN, the extracted orders.
    • Orders Out: When a document extractor is used on MessageDefinition OUT, the extracted orders. 
    • Desadvs In:  When a document extractor is used on MessageDefinition IN, the extracted dispatch advices. 
    • Desadvs Out: When a document extractor is used on MessageDefinition OUT, the extracted dispatch advices. 
    • Standard Business Document Header In (SDBH): A Standard Business Document Header (SDBH) is the effective message sent to a PEPPOL Access Point. It's the UBL message wrapped in an envelop that identifies key data about the document. 
    • Standard Business Document Header Out (SDBH): A Standard Business Document Header (SDBH) is the effective message sent to a PEPPOL Access Point. It's the UBL message wrapped in an envelop that identifies key data about the document. 
    • Message Level Response (MLR):  A Message Level Response (MLR) is a business acknowledgment that tells the sender if the received message follows business rules related to the document type and business flow. 
    • Message Delivery Notification of Message Level Response: A Message Delivery Notification (MDN) of a Message Level Response (MLR) is a proof from the receiver that the MLR was correctly submitted to its destination. 
    • RosettaNet Message Out: The content that was sent by Babelway to the RosettaNet server. 
    • RosettaNet Receipt Out: The RosettaNet delivery report that was received from the receiver of the message, to prove that Babelway has correctly submitted the message to its destination. 
    • RosettaNet Message In: The content that was received by Babelway from the RosettaNet server. 
    • RosettaNet Receipt In: The RosettaNet delivery report that was sent to the caller, to prove that Babelway has received the message. 
    • X400 delivery report:  The X400 message delivery report that was sent to the caller, to prove that Babelway has received the message.
    • SOAP Request: The soap request sent by the SOAP client out gateway. 
    • SOAP Response: The soap response received by the SOAP client out gateway. 
    • NemHandel Message Out: The content that was sent by Babelway to the NemHandel server. 
    • NemHandel Response Out: The NemHandel rasp response that was received from the receiver of the message, to prove that Babelway has correctly submitted the message to its destination. 
    • NemHandel Message In: The content that was received by Babelway from the NemHandel server. 
    • NemHandel Response In: The NemHandel delivery report that was sent to the caller, to prove that Babelway has received the message. 
    • Http request: The response received by Babelway from remote web server, after contacting it to send messageOUT. 
    • Mail In:  The mail message as received by babelway during the smtp exchange. 
    • Chorus deposit summary: The deposit summary report provided by chorus. This helps you understand what went wrong if a file has been rejected. This report is also available in your chorus account. 
    • Too Large Message: The message sent to Babelway but over the environment size  limit. 
    1. Click on Back to list action to return to the list of Messages screen.
    2. Click on Resubmit to reprocess this message. See Resubmitting a Message chapter for more details.
    3. Click on Save As Test Case to create a test case with the data of this message. The new test case is automatically created in the channel that processed the message and populated with the message parameters, including the incoming message that will be used as a test message and outgoing message that will be used as expected message out.

    Changes done in release of November 2015

    • The status Waiting ack has been merged to In progress, because the delivery of the message is not complete. Example: Waiting for the file being downloaded by the client.
    • A message may no longer stay forever in the status In progress. The message processing can only be ended in statuses Success or Error. When applicable, it means that a timeout will terminate the message (for example if a file is not downloaded on a FTP server after X days).
    • Dates and times associated with a message have been reviewed. The available date and times are now Message reception time, End processing time, End processing SLA time and Keep until. See full description of all fields of messages for a full description of every field.
    • Field Acknowledgment reference has been removed. This information is now available in the field Gateway out message status
    • All intermediate files generated during the processing are now saved and are downloadable. This is for example very useful to debug your messages when you have many extra processing (wrappers or unwrappers, replacements based on regular expressions), as you will now have access to the result after each step.

    

    Message details new features screen

    

    

    

    

    

    

    

    

    

    

    

    

    

    

    

    

    

    0 people found this helpful.

    Related Articles