Using CICS deployment tools for enterprise beans

To develop and deploy a bean into CICS®, an application developer, working with a CICS system programmer in the later stages, has to carry out a number of steps:

Develop the bean and make it deployable
Develop the bean and package it into a JAR file. The bean can be written and tested using your choice of tooling.
Note: The JAR file may contain the Java™ classes for one or for several enterprise beans. Typically a JAR file used in a CICS EJB server contains several enterprise beans.
After the bean has been packaged in a JAR file, use ATK to make it deployable. For a short introduction to ATK and a reference to further information, see the CICS Operations and Utilities Guide.
Store in HFS pickup directory
Store a copy of the deployable JAR file in the HFS pickup directory of the CorbaServer in which you want to run the bean. You can do this using FTP, NFS, or SMB. If the HFS directory can be mounted on your workstation, this process can be integrated into the previous JAR file creation process.
Scan the pickup directory
Using either CEMT or the resource manager for enterprise beans, initiate a scan of the pickup directory. (For a description of the resource manager for enterprise beans, see the CICS Operations and Utilities Guide.) CICS creates and installs a DJAR definition for the deployed JAR file in the pickup directory.

After the pickup directory has been scanned, you can view the state of the new DJAR definition to determine if the deployed JAR file is ready for use.

If the deployed JAR file is not ready for use, the cause of the error can be determined and in most cases corrected by an application developer without the need for a system programmer to become involved.

Publish
Publish a reference to the home interface of each bean in the deployed JAR file to an external namespace. The namespace is accessible to clients through JNDI.

If you specify AUTOPUBLISH(YES) on the CORBASERVER definition, the beans in a deployed JAR file are automatically published to the namespace when the DJAR definition is successfully installed into the CorbaServer. Alternatively, you can issue a PERFORM CORBASERVER PUBLISH or PERFORM DJAR PUBLISH command.

The resource manager for enterprise beans (see the CICS Operations and Utilities Guide) indicates if the “autopublish” feature is on or off.

Ensure any additional classes are on class paths
For enterprise beans, you do not need to add the deployed JAR files to the class paths in the JVM profile or JVM properties file. CICS manages the loading of the classes included in these files by means of the DJAR definitions. However, if your enterprise beans use any classes, such as classes for utilities, that are not included in the deployed JAR file, you do need to include these classes on the shareable application class path that will be used by the JVM for the request processor program. Enabling applications to use a JVM tells you how to do this.
Unit Test
Once the beans in the deployed JAR file have been published to the naming server, the application programmer can unit test them in the CICS environment.
System Test
When the beans are ready for system testing, an application programmer can work with a system programmer to consider if any REQUESTMODEL definitions are needed. Use the CICS-supplied transaction CREA to generate REQUESTMODEL definitions. (For a description of CREA, see the CICS Supplied Transactions manual.)

You can identify the beans and bean methods from the application. Your system programmer can associate the bean methods with transaction IDs by causing the optimum set of REQUESTMODEL definitions to be generated. Running different beans under different transaction IDs is useful, for example, for workload-management purposes, and for gathering effective monitoring and statistical information.

Install in production environment
To move from a system test to a production environment:
  1. Use ATK to verify that the container bindings for resources and references that have been set in the deployment descriptor of each JAR file are appropriate for your production environment.
  2. If you have set the DJARDIR parameter in your production region CORBASERVER definition to identify a pickup directory:
    1. Store the deployable JAR file in the pickup directory of the CorbaServer.
    2. Install the CORBASERVER definition.
    3. A suitable DJAR definition is produced.
  3. If not:
    1. Store the deployable JAR file in the HFS directory that you intend to use in the production region.
    2. Install the production CORBASERVER definition.
    3. Create an install a DJAR definition equivalent to that which you had in your test region, using whatever process you would normally use in your installation.
  4. If you have set the AUTOPUBLISH(YES) parameter in your production region CORBASERVER definition:
    1. The beans in the deployed JAR file is automatically published to the namespace when the DJAR definition is successfully installed into the CorbaServer.
  5. If not:
    1. Publish the beans to the JNDI server that you use for production using CEMT PERFORM CORBASERVER PUBLISH or CEMT PERFORM DJAR PUBLISH.
  6. Transfer REQUESTMODEL definitions from the test region CSD to the production CSD using the process that you normally use in your installation.
  7. Ensure that any additional classes, such as classes for utilities, that are not included in the deployed JAR files for your enterprise beans, are present on the shareable application class path that will be used by the JVM for the request processor program in your production system.
Note: If you want to update enterprise beans in a production region, see Updating enterprise beans in a production region.