Using dynamic action blocks for Gen Java applications
Article ID: 214972
Updated On:
Products
Issue/Introduction
With Gen z/OS COBOL server applications using the Action Block property "Dynamically Link" reduces the impact of code changes i.e. the user only needs to regenerate changed Common Action Block (CABs) in a normal (non-component) model or component model and does not have to worry about regenerating PSteps that use them (assuming no import/export view changes between the PStep and used CAB etc).
However, with Gen Java applications the "Dynamically Link" property for packaged Procedure Steps and Action Blocks does not appear to be supported. It is possible to use an Operations Library for CABs in a component model, but there is a requirement to mimic the "Dynamically Link" feature for Java applications i.e. for any type of model (normal/non-component or component) have an Operations Library for used CABs and not include them in the Windows Manager/Server Manager jar file for each PStep that references those CABs. Is it possible to do this via some other means and also how to install/deploy the files to WebSphere?
In effect, this feature will also enable Gen Java applications as Microservices where Component-Based Development (CBD) is not being used.
Environment
Release : 8.62
Component : Gen Enterprise Java Beans, Gen Web Generation, Gen Eclipse Web View, Gen Build Tool
Resolution
It is confirmed that the "Dynamically Link" option is only supported for z/OS.
Creating a single Operations Library for all Java Common Action Blocks (CABs) in a normal model is supported.
However, with the OOTB design of the Build Tool (BT), there is no support for being able to exclude those CAB classes from any Window Manager/Server Manager jar file that contains a PStep that references those CABs. So without manual removal of those used CAB classes from that jar file the concept of using the "dynamic" (centralised) version of those classes in the Operations Library is not possible.
After further research, Broadcom Gen Support has developed an unofficial field solution that involves a new BT Profile USER token and changes to the BT script build_lm_java.scr to prevent the automatic inclusion of CAB classes in the Window Manager/Server Manager jar file.
1. Add new BT Profile USER Token "OPT.JAVA_DYNAMIC_ACTION_BLOCKS" and set to "yes" to use the new feature (Value is case insensitive)
2. Changes to BT script build_lm_java.scr (directory "C:\Program Files (x86)\CA\Gen86\Gen\bt\scripts") in the order they appear in that file.
a. Server Managers:
This section has been changed:
FROM:
+++
<jar duplicate="preserve" jarfile="{LOC.CODE_OBJ}classes/{ICM_FILENAME}/{execunit.MEMBER}.{EJBLMEXT}">
<fileset dir="{LOC.CODE_OBJ}classes/{ICM_FILENAME}"
includes="**/*.{CLSEXT}"/>
</jar>
+++
TO:
+++
<jar duplicate="preserve" jarfile="{LOC.CODE_OBJ}classes/{ICM_FILENAME}/{execunit.MEMBER}.{EJBLMEXT}">
<fileset dir="{LOC.CODE_OBJ}classes/{ICM_FILENAME}"
{* Using dynamic action block option i.e. OPT.JAVA_DYNAMIC_ACTION_BLOCKS=YES *}
{* This is for "EJB"/"EJB Web Services" Server PSteps. Only the PStep member class files are included in the jar file and compiled CAB class files are ignored *}
{[IF]} EQUAL "{$toUpperCase({OPT.JAVA_DYNAMIC_ACTION_BLOCKS})}" "YES"
includes="
{[FOREACH]} PSTEP AS pstep
**\{pstep.MEMBER}*.{CLSEXT},
**\{pstep.NAME}*.{CLSEXT},
**\{pstep.PUBLICIMPORTVIEW}*.{CLSEXT},
**\{pstep.PUBLICEXPORTVIEW}*.{CLSEXT},
{[ENDFOR]}
**\package-info.{CLSEXT}
"
/>
{[ELSE]}
{* Not using dynamic action block option i.e. OPT.JAVA_DYNAMIC_ACTION_BLOCKS=NO *}
includes="**/*.{CLSEXT}"/>
{[ENDIF]}
</jar>
+++
b. Operations Libraries and Window Managers:
This section has been changed:
FROM:
+++
<jar duplicate="preserve" jarfile="{LOC.CODE_OBJ}classes\{ICM_FILENAME}\{execunit.MEMBER}.{JAREXT}">
<fileset dir="{LOC.CODE_OBJ}classes\{ICM_FILENAME}"
includes="**\*.{CLSEXT}"/>
</jar>
+++
TO:
+++
<jar duplicate="preserve" jarfile="{LOC.CODE_OBJ}classes\{ICM_FILENAME}\{execunit.MEMBER}.{JAREXT}">
<fileset dir="{LOC.CODE_OBJ}classes\{ICM_FILENAME}"
{* Using dynamic action block option i.e. OPT.JAVA_DYNAMIC_ACTION_BLOCKS=YES *}
{[IF]} EQUAL "{$toUpperCase({OPT.JAVA_DYNAMIC_ACTION_BLOCKS})}" "YES"
{* This is for operations libraries (OPLIB). The compiled CAB/acblk class is only included in operations library where the acblk oplib property matches the execunit member property of the oplib being processed *}
{[IF]} EQUAL "{execunit.LMTYPE}" "OPLIB"
includes="
{[FOREACH]} ACBLK AS acblk
{[IF]} EQUAL "{acblk.OPLIB}" "{execunit.MEMBER}"
**\{acblk.MEMBER}.{CLSEXT},
{[IF]} NOT_EQUAL "{acblk.IMPORTVIEWNAME}" ""
**\{acblk.IMPORTVIEWNAME}.{CLSEXT},
{[ENDIF]}
{[IF]} NOT_EQUAL "{acblk.EXPORTVIEWNAME}" ""
**\{acblk.EXPORTVIEWNAME}.{CLSEXT},
{[ENDIF]}
{[IF]} NOT_EQUAL "{acblk.LOCALVIEWNAME}" ""
**\{acblk.LOCALVIEWNAME}.{CLSEXT},
{[ENDIF]}
{[IF]} NOT_EQUAL "{acblk.SQL}" "NO"
**\{acblk.MEMBER}${acblk.MEMBER}_EA.{CLSEXT},
{[ENDIF]}
{[ENDIF]}
{[ENDFOR]}
"
/>
{[ELSE]}
{* This is for "INTERNET"/" Web View" Client PSteps. Only the PStep member class files are included in the jar file and compiled CAB class files are ignored *}
includes="
{[FOREACH]} PSTEP AS pstep
**\{pstep.MEMBER}*.{CLSEXT},
{[ENDFOR]}
{[FOREACH]} CLTPSTEP, NONCOOPPSTEP AS referpstep
**\{referpstep.IMPORTVIEWNAME}.{CLSEXT},
**\{referpstep.EXPORTVIEWNAME}.{CLSEXT},
{[ENDFOR]}
{[FOREACH]} SUBORDINATE AS subordinate
**\{subordinate.MEMBER}*.{CLSEXT},
{[ENDFOR]}
**\package-info.{CLSEXT},
**\LoadModule.{CLSEXT},
"
/>
{[ENDIF]}
{* Not using dynamic action block option i.e. OPT.JAVA_DYNAMIC_ACTION_BLOCKS=NO *}
{[ELSE]}
includes="**\*.{CLSEXT}"/>
{[ENDIF]}
</jar>
+++
A modified version of build_lm_java.scr is attached to this article.
NOTE: Before using stop the BT and backup the current version of build_lm_java.scr in directory C:\Program Files (x86)\CA\Gen86\Gen\bt\scripts. Then replace it with the modified version.
Additional Information
NOTES:
The advice given in this article should be regarded as an unofficial "Field Solution" as it has not gone through any official QA testing by Broadcom.
An idea has also been created on the Gen Community for an official enhancement request: Gen Dynamic Deployment on java
With this solution to avoid unnecessary CAB generations.
Using Toolset generation
- The CABs only need to be generated from the Component Generation/Operations Library generation step.
- For the Cooperative Generation of client and server PSteps if the expansion is limited to PStep level in the panel then the CAB code will not be generated, although the CAB *_IA.java & *_OA.java files for CAB import and export views will still be generated
Similarly if using CSE generation.
Usage example:
1. The attached example model a2690353.ief (a2690353.ief.zip) illustrates this feature:
a. Three CABs named CAB1, CAB2, and CAB3.
CAB1 uses CAB2 (both just set an Informational Exit State).
Under Component Packaging, CAB1 and CAB3 are packaged into Operations Library OPSLIB1 and CAB2 is packaged into Operations Library OPSLIB2.
Under Component Generation, expand fully and generate/install Operations Libraries OPSLIB1 and OPSLIB2 using either Java/EJB Web Services or Java/INTERNET (it does not matter which). That creates jar files a2690353.ief\java\classes\OPSLIB1\OPSLIB1.jar and a2690353.ief\java\classes\OPSLIB2\OPSLIB2.jar.
With the modified build_lm_java.scr script, OPSLIB1.jar only contains CAB1*.class & CAB3*.class files i.e. it does not contain any CAB2*.class files.
OPSLIB2.jar contains only the CAB2*.class files (unaffected by the script changes)
b. Two Server PSteps P1 & P2 and which use CAB1 & CAB3 respectively and 2 client PSteps CP1 & CP2 which use CAB1 and CAB3 respectively. So under Cooperative Packaging P1 & CP1 have both CAB1 & CAB2 packaged and P2 & CP2 have both CAB3 & CAB2 packaged.
Under Cooperative Packaging the PSteps are included into Server Managers S1 & S2 and Window Managers C1 & C2 respectively.
Under Cooperative Generation do not expand beyond PStep level (to avoid unnecessary CAB generation) and then generate/install S1 & S2 as Java/EJB Web Services which creates jar files S1.jar and S2.jar in respective directories a2690353.ief\java\classes\S1 & a2690353.ief\java\classes\S2. With the modified build_lm_java.scr script, those jar files do not contain any CAB1*.class and CAB2*.class files.
Under Cooperative Generation generate and install C1 & C2 as Java/INTERNET (Web Generation) which creates jar files C1.jar and C2.jar in respective directories a2690353.ief\java\classes\C1 & a2690353.ief\java\classes\C2. With the modified build_lm_java.scr script, those jar files do not contain any CAB1*.class and CAB2*.class files.
c. NOTE: This solution will also work for Gen Java Web View clients generated from Gen Studio.
2. Under WebSphere:
The attached deploy_test_WebSphere.docx has screenshots illustrating the deployment/testing on WebSphere after the Gen BT steps.
a. Install OPSLIB1.jar and OPSLIB2.jar as shared libraries in the WebSphere Admin Console (Environment -> Shared Libraries)
Use BT Assemble to create a2690353.ear for WebSphere and install that file as a WebSphere Enterprise Application using Detailed Path to be able to reference the 2 shared libraries.
b. Testing the EJB Web Service for PStep P1 (Server Manager S1) from SoapUI using the Diagram trace Utility (DTU) will show CAB1 calling CAB2:
S1/P1: http://hostname:9080/S1/P1/P1.wsdl
c. Similarly, testing the Web Generation client PStep CP1 (Window Manager C1) using the Diagram trace Utility (DTU) will show CAB1 calling CAB2: http://hostname:9080/a2690353/cp1.jsp
3. Under JBoss:
The same solution has been successfully tested for JBoss where OPSLIB1.jar and OPSLIB2.jar are each defined as a custom module rather than a shared library.
In this example, OPSLIB1.jar and OPSLIB2.jar are defined as custom modules opslib1 and opslib2 which are also added as global modules so they can be referenced by all applications (it is assumed CAB names will be unique across all models even if those models have the same java package name defined).
It also assumes that a Gen runtime library has also been previously added as a custom global module gen86_runtime because the OPSLIB jar files will reference runtime classes that need to be resolved by that library and thus oplsib1 and opslib2 will need to define gen86_runtime as a dependency.
The creation of gen86_runtime is described in this KB article: Using shared Gen runtime jar file (genrt.jar) for all deployed JBoss EAP applications
For JBoss under Windows using JBoss CLI to create custom global opslib1 use these steps (commands executed are in bold):
+++
C:\jboss-eap-7.1.0\bin>jboss-cli.bat
You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
[disconnected /] connect localhost:9090
[standalone@localhost:9090/] module add --name=opslib1 --resources=C:\Users\Administrator\Documents\CA\GEN8~1.6\Models\a2690353.ief\java\classes\OPSLIB1\OPSLIB1.jar module --dependencies=gen86_runtime
[standalone@localhost:9090/] /subsystem=ee:list-add(name=global-modules,value={name=opslib1})
{"outcome" => "success"}
[standalone@localhost:9090/] module add --name=opslib2 --resources=C:\Users\Administrator\Documents\CA\GEN8~1.6\Models\a2690353.ief\java\classes\OPSLIB2\OPSLIB2.jar module --dependencies=gen86_runtime
[standalone@localhost:9090/] /subsystem=ee:list-add(name=global-modules,value={name=opslib2})
[standalone@localhost:9090/] quit
Press any key to continue . . .
C:\jboss-eap-7.1.0\bin>
+++
New directories will be created named JBOSS_INSTALL\modules\opslib1\main and JBOSS_INSTALL\modules\opslib2\main which will contain a copy of their corresponding jar file and the new file module.xml. For example JBOSS_INSTALL\modules\opslib1\main\module.xml will contain:
+++
<?xml version='1.0' encoding='UTF-8'?>
<module xmlns="urn:jboss:module:1.1" name="opslib1">
<resources>
<resource-root path="OPSLIB1.jar"/>
</resources>
<dependencies>
<module name="gen86_runtime"/>
</dependencies>
</module>
+++
CHANGE HISTORY:
July 6, 2022:
Updated the attached build_lm_java.scr to correct a problem where the method used to exclude the CAB classes in the Server Manager jar file also removed the inclusion of any PStep classes that those CABs may call/reference i.e. previously only the root PStep classes that called the CABs were included.
Attachments
Feedback
