Use this task when you want to call an Enterprise
JavaBeans® (EJB) application that is deployed on WebSphere® Application Server for z/OS® from an external address space while ignoring
the client transaction context. The only environment where transactional
semantics are supported is Customer Information Control System (CICS®).
Before you begin
The client process must be running on a z/OS operating system
and the client environment must support transactional semantics. The
connection between the client and the WebSphere Application Server
is configured to support transactions. Also, the client must have
called the Register API with the TRANSACTIONAL flag set to the value
of 1.
About this task
The semantics for starting a transaction in the client environment
varies based on the client environment. Refer to the CICS documentation
for information about the semantics for starting a transaction in
a CICS client environment.
Procedure
- Deploy an EJB application on
WebSphere Application Server using a transaction attribute of not
supported, never or requires new on the execute method.
- Start the client program transaction using the transactional
semantics and perform transactional work that is required in the client
environment.
- Use the Invoke (BBOA1INV) API or the Send Request (BBOA1SRQ)
API to make a remote call to the EJB application that is deployed
on WebSphere Application Server for z/OS. The transaction
context propagates to the WebSphere Application Server server, but
the EJB application creates a new local or global transaction context,
depending on the transaction attribute used by the EJB application.
- The WebSphere Application Server server transaction is
committed at the end of the execute method.
- Use the transactional semantics of the client environment
to commit or end the transaction independent of the outcome of the
WebSphere Application Server server transaction.
Results
The new transaction is propagated to the WebSphere Application Server for z/OS. The server ignores the transaction context and drives
the EJB call inside its own unit of work, which commits independent
of the client's unit of work when the EJB call returns.