Skip to content

ABAP Keyword Documentation →  ABAP − Reference →  Data Interfaces and Communication Interfaces 

EPP - Extended Passport

An Extended Passport (EPP) is a data structure that can be sent from a client to a server and is used to analyze call stacks. For the RFC interface, Extended Passports can be sent and received in both ABAP sessions and external communication components such as RFC SDK or JCo. In HTTP communication, this is supported by ICF. In an ABAP session, the Extended Passport is a constant internal data structure in the ABAP kernel and contains information about the session:

  • The Extended Passport is generated with initial values when an ABAP session is created.
  • In communication between clients and servers that support Extended Passport, the client passes its EPP to the server. Here, some components remain untouched and others are set to connection-specific values. If the server is an ABAP session, its EPP contains the values passed from the client.

The most important EPP components are as follows:

The root context ID is a UUID assigned to an ABAP session when it is created. It is unchanged when the Extended Passport is sent to a server and hence identifies the original ABAP session.
The connection ID is a UUID assigned to the connection in question when the Extended Passport is sent to a server. In most cases, an initial connection ID identifies the first component in a call stack. In a server ABAP session, it contains the UUID of the connection. Together with the root context ID, it provides a unique identification for an ABAP session. In most cases, the connection ID keeps the same value when the same connection is reused. If an ABAP session is a stateless APC server, a new connection ID is created each time the server is accessed from the APC.
If a server is accessed using a connection with the same connection ID, the EPP connection counter is usually raised accordingly when the Extended Passport is sent.
The transaction ID is a UUID that identifies a SAP LUW in most cases. The statement COMMIT WORK modifies the transaction ID in non-server ABAP sessions, as long as an update function module was called using CALL FUNCTION IN UPDATE TASK in the closed SAP LUW. The transaction ID is not usually modified when the Extended Passport is sent from a client to a server.
After an ABAP session is created, the component ID contains the system ID of the Application Server ABAP and the name of the application server instance. It is passed to a server without being modified.
When the Extended Passport is sent to a server, the precomponent ID is set to the system ID and the name of the application server instance of the source ABAP session.

Further components can contain additional information.

Other versions: 7.31 | 7.40 | 7.54


Notes

  • Extended Passport can be used by frameworks and analysis tools to track external call stacks in communication between clients and servers beyond system boundaries. The values of the EPP components can be saved to log files and used for monitoring. One example of this are short dumps, which all display the most important EPP components.

  • The method GET_SECTION of the class CL_EPP_GLOBAL_FACTORY can be used to created a handler whose interface IF_EPP_GLOBAL_SECTION accesses the Extended Passport (EPP) of the current ABAP session in an ABAP program.

  • For more information, see Extended Passport (EPP).


Example

The program DEMO_EPP demonstrates the content of the Extended Passport (EPP) components shown above. This program reads these components and saves them to an internal table of a data cluster on the database. This then becomes a log file.

  • Firstly, information about the ABAP session where the program is executed is read. If the ABAP session of the program was not created by an external call, the connection ID and the connection counter are initial.
  • When an RFC connects to another application server instance, the connection ID here is set for this connection and the root context ID becomes the ID of the caller. The precomponent ID contains the component ID of the original session.
  • Any further RFCs from the called RFM set a new connection ID and set the precomponent ID to the system ID and name of the application server instance of the caller RFM.
  • After this, an update runs in the original ABAP session that sets a new transaction ID here.
  • Finally, both RFCs are repeated, with the same connection IDs being set in the called servers as before and the connection Counter being raised by 1 this time. The transaction ID set previously is persisted.