IBM DataPower Operations Dashboard v1.0.11.0
A newer version of this product documentation is available.
You are viewing an older version. View latest at IBM DPOD Documentation.
DataPower Single Transaction
- Copy Page Tree
- Assaf Cohen (Deactivated)
- Sara Weisz
When you click a transaction’s id in the transactions widget, DPOD loads the full details of the transaction into the information window.
This view provides a plethora of information about the single transaction in the following widgets.
Transaction Widget
The widget at the top left of the information window displays the transaction’s time, status, device, domain, service, operation and Client IP.
This information is identical to the information displayed for the transaction in the DataPower Transactions table.
Transaction Analysis Widget
The widget at the top right provides analysis of the transaction in four aspects:
Error analysis
(For transactions in Error status only).
The errors displayed are either network or SSL errors. Transactions that are erroneous as a result of the output policy are not reported here.
If the error is common, DPOD provides a description alongside the error. This is especially useful in situations where the raw logs are
hidden on account of security policies, and cannot be viewed by the user.
DPOD Administrators can also add error analysis descriptions.
Probe Enabled Indicator
If a DataPower probe was enabled during the run of this transaction, an indication will appear ("A probe was enabled for this transaction")
Service Configuration Changes Indicator
If service configuration changes occurred over the last 4 hours/day/week/month, an indication will appear with the number of configuration changes.
Click to drill down into the Service Configuration Changes page. From there, you can view the service configuration changes audit information.
Elapsed Time
A breakdown of the transaction’s elapsed time between network, monitored device and Service Provider.
This analysis lets you view latency data pertaining to the transaction, and potentially identify network congestion or issues.
This data is only available for successful transactions.
Payload Size
Displays the request and response size.
This data is only available since IDG firmware 7.6.0.8 and 7.7.1.2 for transactions of traditional IDG services.
Memory
Memory consumption graphs for the request and response parts of the transaction, across the transaction lifetime and state changes.
The memory graph is designed to display the differences in memory consumption between processing policy actions in a processing rule.
The purpose of this graph is to assist the user in troubleshooting high memory consumption by one or more processing actions (for example when using an inefficient XSLT).
The graph is built using the DataPower “memory-report” records.
In some cases the memory used value reported at the beginning of a transaction is higher than the values following, leading to a negative value in the report.
To investigate the service’s total memory usage navigate to Dashboards → Resources → Service Memory.
The memory graph displays the differences in memory usage values in KB.
Raw Messages Tab
This widget lists the raw messages that make up the single transaction viewed (up to 2000 messages).
Tracking the raw messages making up transactions in error may provide insights into the causes of failures.
Tracking the raw messages making up successful transactions may provide insights into slow components or unnecessary steps.
The information is displayed in a table.
| Column | Description |
|---|---|
Category | The message’s category |
Severity | The message’s severity |
Time | The message’s timestamp |
Direction | The message’s direction. This may be:
|
Object Type | The object type associated with this message |
Object Name | The object name associated with this message |
Client IP | The Client IP this message originated from. This may be the actual client, or a load balancer. |
Message Code | The message’s code |
Message | The actual message logged. |
Payload Tab
When WS-M recording is switched on, the Payload pane of the table will contain payload information for the messages displayed.
The payload is shown for both the front end and the back end, for both the request and response phases.
Extended Latency Tab
Detailed latency information for both the request and response phases.
Side Calls Tab
The side calls tab shows calls made by the DataPower to external resources during the transaction, such as SQL calls, LDAP, HTTP requests, SOAP requests, FTP calls, MQ calls, etc.
| Column | Description |
|---|---|
| Type | The call type - such as SQL, LDAP, etc. |
| Direction | request or response |
| Time | When the call was made |
| Elapsed (ms.) | Elapsed time of the call in milliseconds |
| Status | Whether the call was successful or not |
| Details | Additional details about the call, such as the SQL statement, HTTP request URL, etc |
Correlated Transactions Tab
The Correlated Transactions Tab (Appears only if the user has appropriate permissions), shows all the transactions with the same Global Transaction ID, both Gateway transactions and API-C transactions are shown.
The transactions are sorted by their start time, where the first transaction that run appears on top..
The Trans. ID column displays the transaction ID of the correlated transaction, or "Current" for the current transaction in view. Click the Transaction ID to navigate to the Single Transaction Page of that transaction.
The link will appear only if the user has appropriate permissions to view that particular transaction.
The Service/API column displays the Gateway Service name, or the API Name+API Version.
The Status column displays the transaction status, as shown in the Single Transaction page.
The Message column displays the error message analysis, as shown in the Single Transaction Page. (see "Error Analysis" previously on this page)
Clicking on the Raw Errors links (appears only if the transaction did have any errors, and only if the user has appropriate permissions) will open a window with the all the transactions' error messages, note that the existence of error messages doesn't necessarily mean that the transaction failed.
