Using a session object allows you to process BAPI calls from different business objects within a single transaction, provided the business objects use the DCOM Connector to connect to R/3. In this case, the client creates the corresponding business objects, calls their methods, and terminates the transaction with a database commit.
To enable a transaction to enclose several business objects, you must assign these objects to the same R/3 context. Without the session object, two different business objects have two different RFC connections and thus use their own R/3 context each. The two objects, in this case, are processed in two different SAP LUWs.

The session object generated by the DCOM Connector implements the interface ISAPSession, which in turn is deviated from the ISAPConnector.
Using the ISAPSession interface, the client can

• log on to the R/3 system
• create one or more logically related business objects with the same R/3 context
• submit the DB commit in the target system (if necessary).

Even if the client does not explicitly submit a commit via the session object, using a session object has one significant advantage:
It allows you to keep an RFC connection for a longer period of time. All objects created for one session share a single connection. Transferring the required connection data happens once per session.

If you use the session object, you can instancize business objects only "in process". This means either that the session component is installed in the common MTS Package together with the respective DCOM business objects or that all components are assigned to a library package. However, keep in mind that using a library package has significant disadvantages since it deactivates the relevant security checks. In this case, there is no process limit and the DLL runs in the process area of the client application.

We recommend to install a separate session object for each package.
The DCOM Object Builder helps you to generate and install a session object in the MTS.

The diagram below demonstrates how a session object works in interaction with two object instances.

• To start a transaction, the client creates a session object. It then transfers all logon data relevant to the RFC connection. The session object can now establish a connection to the R/3 system. However, logon must not take place immediately but can be started together with the first BAPI call at the latest.

• The created session object can now instancize two business objects. These two objects then use the same R/3 context.

• The client calls the BAPIs as usual. Business objects receive the required RFC connection from the session object that instancized them. Both BAPI calls are executed in the same SAP LUW.

• After the client submitted a commit for the session, the connection is no longer needed. Method CommitWork( ) is called to trigger the ABAP Commit Work in the R/3 system. Any changes made within the session are written to the R/3 database. In addition, an implicit SetComplete( ) is called to release the resources assigned in the client process.
  

Which components are included in a generated session object ?