Skip to main content
Transaction Manager: Reading Logs

Want to see what data is being communicated between Transaction Manager and your ERP? This guide will provide a basic overview.

Micah A. Parker avatar
Written by Micah A. Parker
Updated over a year ago

Product: Transaction Manager, Integration Service


A lot that happens behind the scenes when you try to pass data to and from your Enterprise Resource Planning (ERP)/business system and Transaction Manager. By enabling log tracing you can see the data that is being communicated behind-the-scenes in order to help identify errors or even validate data being passed to and from your system.

NOTE: If your system is a simple Flat-File integration where we are simply creating or reading a comma-separated value (CSV) or Extensible Markup Language (XML) file to interact with yours, then no log will be produced, as there is no communication with your system happening directly.

Enabling a Trace Log


There are two ways Transaction Manager logs information:

  • locally (for ERP systems that are installed/accessed locally such as QuickBooks (On-Premise), Sage 100, Dynamics GP [Standard/Advance], and SAP Business One)

  • Cloud Logging for Web-Browser based ERPs such as Acumatica, Dynamics 365 Business Central, Netsuite, and QuickBooks Online

Reading Logs


Once a log is obtained through either of the aforementioned methods, you will receive a file with all the information passed back and forth between your business system and Transaction Manager, including Import/Export requests, SQL Stored Procedure calls, and connection attempts.

Although every business system is different there are a few things to keep in mind that can help you understand the data being passed back and forth.

Key Concepts


Note the following key concepts:

  • All data is from the Transaction Manager perspective. As such, an Import would imply Outbound data being imported into Transaction Manager and Export would imply Inbound data being exported out of Transaction Manager.

  • Requests and Responses are paired together to create a complete process. A Request is made and a response is given to that request.

  • Data can often get converted to fit Transaction Manager or your ERP better.

    • Example: XML gets converted to JSON and vice-versa for Dynamics 365 Business Central customers.

  • Errors can be produced by either Transaction Manager or your ERP.

Requests and Responses


Every integration between Transaction Manager and your ERP is accomplished through a combination of a Request and a Response. Together, they produce a complete round-trip of information that lets Transaction Manager or your ERP know whether something was successful or failed.

Examples of Requests/Responses:

  • Connection Attempts

  • Authorization

  • Database Access

  • Import or Export of Transactions

  • Data Syncing (Inventory/Partner Lists)

  • Inventory Feeds

Requests

Since Transaction Manager is what initiates the interactions (as your ERPs do not know about Transaction Manager directly), everything that is a Request is asking your ERP to do something, whether that means allowing Transaction Manager to log in, or your ERP to create a new Sales Order, or your ERP to send Transaction Manager all of its Inventory.

This request is sent to your ERP and Transaction Manager then begins to wait for the Response from your ERP. If no Response is received (due to timeouts, inability to connect, or another reason), the Request will fail and Transaction Manager will not complete its process.

Responses

The Response is essentially the answer to the Request previously made. If Transaction Manager previously asked your ERP to create a new Sales Order and your ERP returns a Response stating it was successful, then Transaction Manager assumes everything went well and continues to push the transaction into its Outbox.

If, however, the Response states it failed, Transaction Manager will return the error code provided by your ERP within the Integration Activity and alert the user or scheduler that it was unable to complete the initial Request.

Finding Requests/Responses


While each system is slightly different in their interactions to accommodate each ERP individually the overall theme is the same. Each Request or Response is going to be labeled with a Request/Response identifier along with the type of interaction, be it a Connect() or a ExportTransaction().

Requests Examples

REQ GET

SendRequest()

xmlRequest

Response Examples

RESP JSON

xmlResponse

Transaction Requests/Responses


If you are looking to find Transactional data, you can search for ExportTransactions() or ImportTransactions() within the log to begin finding the data.

NOTE: Since your Request/Response is based from Transaction Manager's point of view (if you are looking for the initial XML data being sent from Transaction Manager), it will flip-flop based on the operation.

Export

If you are exporting from your Inbox, the XML will be sent from Transaction Manager initially in the ExportTransactions() xmlRequest (or REQ) for example, since Transaction Manager is requesting that your ERP creates an order (for example, from the provided data); meaning, the ExportTransactions() xmlResponse (or RESP) would provide the success/fail information from your ERP in response to that request.

ExportTransactions() xmlRequest

ExportTransactions() xmlResponse

Import

If you are attempting to import data from your ERP into the Outbox, your ImportTransaction() xmlRequest (or REQ) would be simply Transaction Manager asking for the specified Document # asking for your ERP to send that information over. The ImportTransactions() xmlResponse (or RESP) would then provide the data formatted in XML from your ERP that Transaction Manager is reading and as such, you can see what data was sent over.

ImportTransactions() REQ

ImportTransactions() RESP

rev: 7/30/23

Did this answer your question?