JMWE Logs
The JMWE Logs administration page (Figure 1, right) details the most recent events logged by JMWE for your Jira Cloud instance. From here, you can configure the logging level for JMWE installation, configure Webhooks to receive JMWE log messages, and search for specific logs.
You must be logged in as an administrator to view or use this page.Â
Logging level
The Logging Level determines which types of system events are captured by JMWE. By default, events with a level below INFO are not stored and therefore cannot be included in the logs. However, for troubleshooting purposes, it is possible to temporarily increase the level of logging.
To set a temporary log level:
Select the required level from the Temporary log level pulldown menu.
Click Apply.
The new level set here will remain for one hour, and will thereafter revert to the default INFO level.
Click Reset to the right of the pulldown menu to revert the log level to the default INFO level.
Send errors and/or warnings to a Webhook
A webhook can be used to send errors and warnings for your JMWE post-functions and actions to an external applications for monitoring or other processing.Â
To configure a webhook, enter the following:
Webhook URL - Enter the URL for the location to which any errors and/or warnings should be sent.
Send - Choose whether to send Errors and Warnings or Only Errors.Â
Receive log entries - Configure how to send messages to the webhook URL. The options are:
Single entry - Log messages are sent one at a time; if a message includes more than one error and/or warning, it will be broken into multiple messages.
Grouped (when possible) - Log messages will not be separated when they include more than one error and/or warning. Messages that include only one error or warning will still be sent as one message.
Click Apply.
When an error or warning (depending on configuration) occurs, the webhook will post the error data in real-time.
Log viewer
By default, the logs from the last 24 hours with a level higher than INFO are displayed in the table. You can filter the logs based on several conditions:
When - when the logs were created (when the event occurred)
Level - The range of levels to include in the output. Events can be filtered on any level from DEBUG all the way up to FATAL.Â
Extension IDs - Logs can also be filtered based on the ID of any extension that has been created, including:
Post-function ID
Condition ID
Validator ID
Action ID (for Shared Actions)
To find the ID of a post-function, condition, validator, or Shared Action, open the extension in the transition in the Workflow editor; the ID will be listed under the name of the post-function in the transition information screen.
Additional filters are available; click More filters to expand the list and access the following:
Message type - Filter by message type, e.g. security-error, template-error, workflow-warning etc. Select a message type from the pulldown menu.
Post-function - The post-function that was executed. Select a post-function name from the pulldown menu.
Condition - The condition that was executed. Select a condition name from the pulldown menu.
Validator - The validator that was executed. Select a validator name from the pulldown menu.
Workflow name - Filter by a specific Workflow. Enter the Workflow name.
Transition name - Filter by a specific transition. Enter the transition name.
Issue key - Filter for a specific issue. Enter the Issue ID.
Username - Filter based on the user who triggered the transition.
Execution ID - Filter based on an execution ID, which can be copied from Context; see below for more information. Context; see below for more information.
Click on Apply filters to filter the logs.
Entries
Please note: Not every tab or field listed below will be displayed at all times. Only the tabs and fields appropriate to the log will be displayed.
Only the 200 most recent events that match your filters are displayed in the table. Each entry has the following information:
Timestamp
Level
Workflow Extension
Message Type
Message
In most cases, the failure details are displayed in the Message. If the Message isn't sufficient to debug the problem, click '>' to the left of the log entry to see the additional information:
Error details - Displays any additional error details. This tab will only appear on error logs.
Error code
Error message
Field error(s) - Displays for errors related to specific fields.
Context - Displays the context of the log entry.
Account ID - The account ID number for the user who triggered the transition, e.g.
557058:72911e75-a89c-402e-b2f4-054c6bXXXXXX
.During - which process the entry was created, e.g.
post-function-execution
.<Extension> ID - The ID number of the extension that encountered the error. Click add to filters to copy the ID value to the corresponding filter field.
Execution ID - The ID of the specific execution of a post-function. This allows you to search for all events generated by a single execution of a post-function. Click add to filters to copy the ID value to the filter.
Transition Execution ID - The ID of the transition execution that triggered the error.
Issue key - The ID of the Jira issue which triggered the error.
Timings - Timing data related to the extension which encountered the error.
Delay - The delay before executing the extension.
Execution - The total time for executing the extension.
Queue - The total time the extension spent in the queue.
Triggering - Time spent to bootstrap the execution, in case of triggered events.
Jira REST API call - Displays information on the call made to the Jira API
Method - Method used. Eg: PUT, GET, etc.
Url - REST Url.
Data - Object or value sent to Jira to set a field.
Post-function or Condition or Validator - Configuration details for the extension that caused the error
Post-function/Condition/Validator - Name of the extension.
Transition - Transition name and Workflow name in which the error occurred.
Configuration/Jira Expression
Action - For Shared Actions, data for the action that caused the error.
Action Name
Action Id - The ID of the Shared Action. Click add to filters to copy the ID value to the Action ID filter field.
Action Execution Id - The execution ID for the Shared Action. Click add to filters to copy the ID value to the Action Execution ID filter field.
Type - The type of Shared Action.
Download logs
Once you have filtered the logs as needed, they can be downloaded for analysis. Follow these steps to download your filtered logs:
Under Download logs, select a format from the Format pulldown menu:
JSON
Text (short)
Text (detailed)
Text (dev)
Click Download logs.
The logs displayed in the table will be downloaded in the format selected. The download is limited to 200 events at most that match the filters selected.
Using logs for troubleshooting
If any JMWE extensions in your workflow do not seem to be working as expected, you can investigate possible issues or failures from these logs. The example scenarios below detail how to troubleshoot.
1 - Failure to create an Epic using ‘Create issue(s)’ post-function
Filter your logs
Go to JMWE Logs page.
Under the Log viewer section, click More filters.
Select
Create issue
from the Post-function pulldown menu.Click Apply filters.
The table displays your filtered logs.
Analyzing the logs
The first thing to do is look at the Message value (the last column of the table) for the specific error/warning message:Â
Message: The post-function failed to create the Epic because the Epic Name was not provided, which is a mandatory field when creating an Epic.Â
2 - Failure to set the Component/s field to "Backend,Testing" using the ‘Set field value’ post-function
Filtering your logs
Go to JMWE Logs page.
Under the Log viewer section, click More filters.
Input the Issue key in Issue key filter.
Click on Apply filters.
The table displays your filtered logs.
Analyzing the log
The first thing you need to do is look at the Message value (the last column of the table) for the error/warning message:
Message: The post-function failed to set the Component/s field with a component name "Testing".Â
Click on > of the log entry and lookinoking at Jira REST API call willwill display information on what value hhas been been passed to Jira:
Jira REST API call:Â The Data shows that two component values -Backend
and Testing
 - were passed to Jira instead of one (i.e. "Backend,Testing"
). The comma(',') was considered as a delimiter in the array of values rather than a part of the component name. So you need to pass the value as JSON object ([{"name":"Backend,Testing"}])
selecting the "Treat value as JSON"
option in the post-function configuration.
3 - Determine impacted issues when using ‘Set field value of linked issues' post-function
While iterating over linked issues to set a field value using the Set field value of linked issues post-function, there is no way of knowing which issues were impacted. In this circumstance, you might want to set the Temporary log level to DEBUG and trigger a transition that has the post-function.
Filtering your logs
Go to JMWE Logs page.
Select
DEBUG
infor Level.Under the Log viewer section, click More filters.
Select
Set field value of linked issues
from the Post-function pulldown menu.Click Apply filters.
The table displays your filtered logs.
Analyzing the log
The table now has DEBUG entries indicating the setting of the field on the impacted linked issues.
Using error and warning data posted to a webhook
When using a webhook, the raw content is sent as a JSON file.
You can use this raw content to construct your own logging messages in external applications.