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.