Get Example source ABAP code based on a different SAP table
Extended Passport (EPP) 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 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, certain components remain unchanged and others are set to connection-specific values. If the server is an ABAP session, its EPP contains the values passed by the client. The most important EPP components are as follows:
EPP root context ID The root context ID is a UUID that is assigned to an ABAP session when it is created. It is unchanged when the Extended Passport is passed to a server and hence identifies the original ABAP session.
EPP connection ID The connection ID is a UUID that is assigned to a server of this connection when the extended passport is passed. In most cases, an initial connection ID identifies the first component in a call stack. In an ABAP session that acts as a server, the connection ID contains the UUID of the connection. Together with the root context ID, it provides a unique identification for an ABAP session. If the same connection is used repeatedly, the connection ID keeps the same value. If an ABAP session acts as a stateless APC server, a new connection ID is created each time the server is accessed from the APC.
EPP connection counter 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 passed.
EPP transaction ID The transaction ID is a UUID that usually identifies an SAP LUW. The statement COMMIT WORK modifies the transaction ID in an ABAP session that does not act as a server if an update function module was called using CALL FUNCTION IN UPDATE TASK in the SAP LUW closed with COMMIT WORK . The transaction ID is not usually modified when the extended passport is sent from a client to a server.
EPP component ID 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 modification.
EPP precomponent ID When the extended passport is passed to a server, the precomponent ID is set to the system ID and the name of the application server instance of the passing ABAP session. Further components can contain additional information.
Latest notes:
Extended Passport can be used by frameworks and analysis tools to track external call stacks in communication between clients and servers across system boundaries. The values of the EPP components can be collected in log files and used for monitoring. One example of this are short dumps, which list 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). ABAP_HINT_END
Example ABAP Coding
The program DEMO_EPP demonstrates the content of the extended passport (EPP) components listed above. This program reads these components and adds them to an internal table of a data cluster on the database that serves as a log file.
First, 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 inherits the ID of the caller. The precomponent ID contains the component ID of the original ABAP session.
A further RFC from the called RFM sets a new connection ID and sets 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, whereby the same connection IDs are set in the called servers as before and the connection counter being raised by 1 this time. The transaction ID set previously is persisted. ABAP_EXAMPLE_END
