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: FieldDescriptionExampleDateDate when request was received.Fields Date and Time are set automatically for system messages.Custom log messages written with the (25.3) Log Adapter or the (25.3) report() Operation can contain a custom timestamp. This may result in log messages that are not sequential.2018-06-06TimeTime when request was received.08:02:45Time ZoneTime zone offset+0200Transaction 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.00000002d3b0bdc0000069ce00ff9700ea65376fRequest IDUnique ID of request.101Component NameName of component that has been requested (not the name of the xUML service).urn:Services.SupportCase.SupportAPI.supportcases.GETElapsed TimeElapsed 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_ENTERreading the request data from the networkparsing the request body (e.g. SOAP)after SERVICE_EXITcreating the response (e.g. SOAP)sending the response to the client36StateState is either OK or ERROR.OKDomainIf 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.INTERFACELog TypeSERVICE_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 2Parameters, 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.75Correlation IDUnique 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, JMSservices receiving a correlation ID: SOAP, HTTP, SAP, JMS ListenerFor 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() Operation) and you can pass it on in your service model.