Logs are available to be viewed directly within Cloud Studio for any operations that have been deployed and executed within a project (see Operation Deployment and Execution). Logs can also be viewed through the Activities page of the Management Console.
Accessing Operation Logs
Operation logs can be accessed within Cloud Studio at the project, workflow, or operation level. Depending on where they are accessed, the operation log screen includes logs for all operations that have been deployed and executed within a project, within a particular workflow, or for a particular operation, respectively. If operations are linked with operation actions, logs for downstream operations are also included.
Project Index Card View: Click the project card tile to enter card view. Then hover over a project card and click the actions menu icon to open the actions menu. From the menu, select Logs:
Project Index List View: Click the project list tile to enter list view. Then hover over the empty cell in the column labeled with an actions menu icon and click the additional actions menu icon to open the actions menu. From the menu, select Logs:
Project Pane: Click the actions menu icon to open the actions menu. From the menu, select View Logs:
Logs can be accessed for operations that have been executed within a particular workflow from the project pane in the Workflows tab. Hover over a workflow name and click the actions menu icon to open the actions menu. From the menu, select View Logs:
Project Pane: In the Workflows or Components tab of the project pane, hover over an operation name and click the actions menu icon to open the actions menu. From the menu, select View Logs:
Design Canvas: In the top right of an operation, hover over the actions menu icon to open the actions menu. From the menu, select View Logs:
Viewing Operation Logs
The operation log screen displays a table of operations that have been deployed and executed with the selected project or workflow, or for a specific operation (see Operation Deployment and Execution). If operations are linked with operation actions, logs for downstream operations are also included. Child operation logs are sorted in the order the operations were executed (that is, by Time Started). You can limit the information displayed in the table by filtering or searching.
The table includes the columns described below:
- Operations: The operation name.
- Status: The status of the operation. For a complete list of possible statuses, see Filter by Status below.
- Time Started: The date and time the operation began running.
- Time Done: The date and time the operation stopped running.
- Environment: The environment that the operation was executed in. A different environment than the one you are currently using may be listed if, for example, you executed the operation in one environment, migrated the project to another environment, and then executed the operation there.
- Details: Click the plus icon to expand the log details or the minus icon to close the log details. The log details include the number of source and target records processed and log messages. Under certain circumstances, a Try Again button button may be displayed, covered under Operation Retry, below.
If an operation fails with an error related to file dependencies, this issue may be resolved by resyncing the project between the agent and Harmony. In this scenario, a Try Again button appears within the operation log:
Upon clicking Try Again, the project will be resynced between the agent and Harmony.
After the resync is complete, the operation run will automatically be retried. If successful, a success status will be displayed in the new operation log. If the operation again fails, additional attempts to synchronize the agent won't help and the reason for the failure may be due to something else (contact support for assistance).
Filter by Timeframe
To filter logs by timeframe, manually type in the date and time range in the same format that it appears. By default, the past 24 hours of logs are shown.
The initial logs are displayed based on the date and time that the log screen was opened, as displayed at the top of the table. Logs will be automatically refreshed every five seconds if any operation is still in a running state (status of Received, Submitted, Pending, or Running). You can also manually refresh the logs at any time to display updated information.
To manually refresh the logs, click Refresh:
Upon clicking Refresh, the ending timeframe of the log will be reset to the current date and time.
Filter by Status
To filter logs by operation status, use the dropdown at the top of the table. The filter is currently limited to select statuses. All possible statuses that may be displayed in the table are listed below.
- All: All operations are displayed regardless of status.
- Error: If the agent completes the execution of an operation, but there was a fatal error in writing to the target system, or there was a fatal validation error in the transformation, or the transformation logic triggered the
RaiseError()function, then the operation status is set to Error and the operation execution terminates.
- SOAP Fault: If the agent completes the execution of an operation, and the outcome was a SOAP fault, then the status is set to SOAP Fault. This status is applicable only for operations using SOAP activities or Salesforce activities.
- Submitted: When operations are submitted to the Harmony queue, but have yet to be picked up by an agent for execution, they will have a Submitted status. Operations can be submitted by several means:
- Jitterbit scheduling service or external scheduling service
- Manual execution of the operation in Cloud Studio
RunOperation()function from a script or transformation
- Any tool, including
JitterbitUtils, that calls the Jitterbit Harmony API
- Received: Once an agent is picked and the agent has acknowledged that it has received the request to run an operation, the status is changed to Received.
- Pending: Once an operation is scheduled to run in an agent's operation engine, the status is changed to Pending. Operations should not be in Pending status for long durations, as agents should pick up the request and start running operations in a short amount of time.
- Running: Once the agent starts executing an operation, the status should change to Running. Operations will remain in this status until they complete or they encounter an error. Jitterbit will start logging messages generated by the operation as it runs so that users can track which part of the operation is currently being executed.
- Cancel Requested: If a user wants to stop an operation that is in Submitted, Received, Pending, or Running status, they can do so from the Activities page of the Management Console. Alternatively, they can enable another operation to cancel an operation using a combination of the
CancelOperation()functions. Once a cancel is requested, the operation status will change to Cancel Requested. An operation should not remain in this status for long, as the agent should cancel the operation in a fairly short period of time.
- Canceled: Once an agent cancels an operation, it sets the status to Canceled and the operation is terminated. All log information up to the point of cancellation will be available for review in the log messages, so the user will know at which point the operation was canceled.
- Success: Once an agent completes the execution of an operation, if the outcome was a success without warnings from the target system, or warning written in the transformation using the
WriteToOperationLog()function, then the status is set to Success.
- Success with Info: If the agent completes the execution of an operation, but there were non-fatal issues in the transformation or posting to the target system or the
WriteToOperationLog()function was used to write messages to the log, then the status is set to Success with Info. This alerts the user to check for information in the log messages.
- Success with Warning: If the agent completes the execution of an operation, but there were non-fatal issues in the transformation or posting to the target system, and there was a warning, then the status is set to Success with Warning. This alerts the user to check for warnings in the log messages.
- Success with Child Error: If the agent completes the successful execution of an operation, but within one or more child operations, there was a fatal error in writing to the target system, or there was a fatal validation error in the transformation, or the transformation logic triggered the
RaiseError()function, then the operation status is set to Success with Child Error. This status does not apply to asynchronous operations.
Click the search icon to expand a search box where you can enter keywords that will be searched for within the operation name:
Last updated: Jul 15, 2019
- No labels