You can use the information that is logged to the transaction log for performance measurements or statistical evaluations (for instance, how often the transaction has been called, in which context, etc.). There is one log file per day or one per hour – depending on what has been configured in the transaction log rotation interval of the service preferences (see Preferences of an xUML Service). The amount of data that is logged depends on the selected transaction log level (see Transaction Log Levels).

How to search the logfiles is explained in detail on Logging of xUML Services.

The transaction log contains the following information:

FieldDescription
Example
DateDate when request was received.Fields Date and Time are set automatically for system messages.
Custom log messages written with the Log Adapter or the report() Function can contain a custom timestamp. This may result in log messages that are not sequential.		2018-06-06
TimeTime when request was received.08:02:45
Time ZoneTime zone offset+0200
Transaction IDUnique ID of the transaction. It is used to trace service calls through the call stack (see Transaction ID). The transaction log contains the first 40 characters of the transaction ID.00000002d3b0bdc0000069ce00ff9700ea65376f
Request IDUnique ID of request.101
Component NameName of component that has been requested (not the name of the xUML service).urn:Services.SupportCase.SupportAPI.supportcases.GET
Elapsed Time

Elapsed time, for each call (service calls, external or internal calls) in milliseconds.

If the elapsed time is displayed as "0", the logged step has taken below 1 millisecond of time. The value of elapsed time does not contain:

  • before SERVICE_ENTER

    • reading the request data from the network

    • parsing the request body (e.g. SOAP)

  • after SERVICE_EXIT

    • creating the response (e.g. SOAP)

    • sending the response to the client

36

StateState is either OK or ERROR.OK
Domain
  • If an adapter has been called, the domain fields contains a value denoting the adapter, for instance SAPRFC, SQL, FILE, SYSAD, POP3, URL, etc.
  • If a service operation has been called, the value is INTERFACE.
  • If a log entry has been triggered by the user via the logger adapter, the value was defined in the UML model.

INTERFACE

Log Type
  • SERVICE_ENTER or SERVICE_EXIT marks the begin/end of a service call.
  • TRANSITION_ENTER or TRANSITION_EXIT marks the begin/end of persistent state transition handling.
  • DOACTION_ENTRY or DOACTION_EXIT marks the begin/end of a persistent state do activity.
  • IO_ENTER or IO_EXIT marks the begin/end of an IO operation, like e.g. an adapter call.
  • If the logger adapter triggered the log entry, the value is CUSTOM.

SERVICE_EXIT

Parameter 1 and 2
  • Parameters, for instance, if the file system adapter has been called, the first parameter corresponds to the executed action (e.g. ReadDirectory) and the second one to the specified file.
  • If the logger adapter triggered the log entry, the first parameter corresponds to the description defined as input for the adapter in the UML model.

anonymous 2.0.232.75

Correlation ID

Unique ID that relate an adapter call with the adapter response. The transaction log contains the first 40 characters of the correlation ID.

A correlation ID is available for the following:

  • adapters sending a correlation ID: SOAP, URL, SMTP, SAPRFC, Persistent State, JMS
  • services receiving a correlation ID: SOAP, HTTP, SAP, JMS Listener

For more information refer to the adapter pages.

00000011e33a4f8400004fc4000043ac9bc69bee

Usually, you will not analyze the transaction log within the Bridge, but download the log file. Then you can have a look at it either in Excel ...

... or analyze it with the Analyzer.

Transaction ID

The Transaction ID identifies a transaction. It is a unique number used to trace service calls through the call stack of multiple service calls.

  • Runtime 2019.9  Clients calling a service running on the Bridge can provide a transaction ID in HTTP header X-Transaction-ID or xTransactionId (in JMS context).
  • SOAP clients can also use the SOAP headers to provide a transaction ID.
  • If an xUML service is called without providing a transaction ID, the xUML Runtime will generate such an ID.

This ID will be passed on through the call stack of the xUML service, so that the whole transaction can be traced. This can be useful, when analyzing the log file in case of error.

In the Analyzer, the transaction log will be sorted by transaction ID. You can expand the tree of a transaction ID to inspect the sequence diagram of this transaction in the panel on the right.

While modeling services with MagicDraw and Builder, you have access to the received transaction ID (getTransactionID() Function) and you can pass it on in your service model.

On this Page:
Related Pages:
  • No labels