Skip to end of metadata
Go to start of metadata

Introduction

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.

WARNING: For security, logs from agents in a Cloud Agent Group are removed as soon as they are no longer required for an operation to execute properly. In addition, downloading of operation logs through the Management Console Activities page is disabled on agents in a Cloud Agent Group.

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.

By Project

Logs can be accessed for all operations that have been executed within a project from the project index in either card view or list view, or from the project pane:

  • 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.

By Workflow

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.

By Operation

Logs can be accessed by operation from the project pane in both the Workflows and Components tabs, and from the design canvas:

  • 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 within 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.

TIP: Basic configuration of what is included in the operation log is specified under the Options tab of the operation settings (see Operation Options). For more advanced information about other logging options, see Enabling Debug Logging.

Filter by Timeframe

By default, the Start Time Range is configured so that the past 24 hours of logs are shown:

The date and time for time range selection uses local browser time. Hover over the Start Time Range tooltip to see the local browser time zone.

There are several ways to change the timeframe by which the logs are filtered:

  • Manually type in the date and time range in the same format that it appears.
  • Click to highlight an area of the date or time, then hover over the field and use the up or down arrows to increase the date or time by a single unit:

  • For the date field only, hover over the field and use the dropdown arrow to select a date from the calendar datepicker:

Refresh Logs

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, ReceivedPending, 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 GetOperationQueue() and 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.

Search within Logs

Click the search icon  to expand a search box where you can enter keywords in the specified format that will be searched for within the logs.

A percent symbol (%) can be used as a wildcard at the beginning and/or end of a keyword.

By Project or Workflow

When viewing logs for the entire project or for a workflow, you can search by operation name or by message within the operation log:

  • Operation: Searches by operation name must be specified in the format of operation=keyword.
  • Message: Searches by message must be specified in the format of message=keyword.

Only a single operation keyword and single message keyword are supported. When both an operation keyword and a message keyword are provided, the keywords are treated as a combination; that is, operation logs will be returned that match both the operation keyword and the message keyword.

By Operation

When viewing logs for a single operation, you can search by operation log message only:

  • Message: Searches by message must be specified in the format of message=keyword.
TIP: For additional log search capabilities, you can also view logs through the Activities page of the Management Console.

View Logs

The log 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, displayed as the local browser time.
  • Time Done: The date and time the operation stopped running, displayed as the local browser time.
  • 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.

    NOTE: Dates and times displayed within the logs themselves are not converted to local browser time, but are reported in their original format from the source of the log message.

Operation Retry

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).

NOTE: A Harmony Agent that is version 10.1 or higher is required for the operation retry to work. If using a lower agent version, the Try Again button still appears but doesn't function.
On This Page

Last updated:  Nov 08, 2019

  • No labels