Debug Report
Last updated
Last updated
A debug report can be generated for jobs to test a job's configuration before actually delivering the content.
A debug report can be generated by running a debug job. This can be done by opening the run job options and selecting "Run Debug".
This will start a new transaction for the job. Once the transaction is finished the Debug Report can be viewed.
A pipeline can also generate debug reports for jobs.
When editing a pipeline, each job can be set to run in debug and generate a debug report for that job.
You can tell which jobs will run in debug mode if the bug icon is filled in.
In the above example, the article -> article
job will be run in debug while the other two jobs will not.
To set which jobs in a pipeline should generate a debug report, simple press the bug icon and the debug option will be toggled. (If the debug option is set, pressing the bug icon will remove the debug option, leaving the job to run normally. And vice versa.)
When the pipeline runs, it will run as normal. With the exception that any job with the debug option set, will run in debug mode with the appropriate rules of a debug transaction.
There are a few rules to a debug transaction.
A debug transaction will limit the amount of content picked up from each system to 1.
A debug transaction will not deliver content. It will run all the steps like a normal transaction except it will not deliver the content to the system.
A debug report can be downloaded and viewed by going to the reports page. Find the transaction that was run with the debug option and open the "action" menu and press "Download Debug Report"
This will then download the debug report in a JSON file. This file can then be viewed with your preferred JSON viewer.
Note: if the debug report does not exist (or couldn't be downloaded) for a transaction, a notification will appear stating that the report does not exist.
The debug report has 5 attributes in the root JSON object.
transactionId
The transaction ID that generated the report
originalContent
The content as Motation after being picked up from the source system
manipulators
The content as Motation after each manipulator has been run
contentMapping
The content as Motation after the content mapper (including field locking) before being delivered to the destination system
advanced
Additional details for advanced users of the system and Motiv support
The originalContent
, manipulators
, and contentMapping
attributes all share a common JSON object which will be referred to as a "content" object.
A content object has the following JSON structure.
This content object can be copied and pasted into the liquid template playground to test liquid templates against the values from the content object.
The originalContent
attribute is the content after it was picked up from the source system and transformed into Motation. The value of this attribute is an array of content objects. Often each content object is a different language of the content.
All manipulators and content mapping will happen after the original content.
The manipulators
attribute is the content object after each manipulator runs. The value of this attribute is an array of JSON objects with an attribute which is the name of the manipulator and the order it was run compared all other manipulators. Each manipulator then has an inner JSON object with the attribute "content" which is an array of content objects.
An example of the format for this JSON can be seen below.
The manipulators are listed in the order that they ran during the transaction.
If a manipulator adjusted folders, then the changes to the folders will be seen in the attribute "folder" rather than "content".
The contentMapping
attribute is the content object after the content mapper has run. This includes any locked fields as well as mapped fields. The value of this attribute is an array of content objects.
The advanced
attribute can often be ignored and is for users with a deep understanding of ImpulseSync or Motiv support. This attribute will contain additional data that can prove useful in select cases where a view of the definition for the content is required.
Debug reports can be deleted from storage by going to the reports page, scrolling to the bottom of the page, and pressing the "Delete All Debug Reports" button.
This will then open a confirmation modal to confirm you want to delete all debug reports. To continue with the deletion process, press the new "Delete All Debug Reports" button.
This will then close the confirmation modal and start the deletion process for all debug reports.
When the for a job are configured, the job will automatically remove the debug option. Be sure to check that the debug option is set appropriately after setting start transaction options for a job.
This would be the same as option to 1.