Applying DevOps to Java applications
This chapter demonstrates how the new DevOps tools in CICS Transaction Server V5.3 can be used to create reliable and repeatable automated build and deployment processes for web applications within Liberty JVM servers on CICS Transaction Server.
This chapter covers the following topics:
6.1 Java application scenario
The application that we use in this scenario is the same GENAPP application that is used throughout this book, with an extension that uses the WebSphere Application Server Liberty profile in CICS. The purpose of using the Liberty extension for GENAPP is to demonstrate the ability to use Java and web technologies along with traditional COBOL code. You can download the GENAPP extension from IBM Support at this website:
Here are the DevOps tools that you use in this chapter:
•Integrated developer environment (IDE): CICS Explorer
•Source code management (SCM) system: Rational Team Concert (for the web application source code)
•Build: IBM CICS Transaction Server build toolkit (CICS build toolkit)
•Deployment: DFHDPLOY utility
The high-level design of the build and deployment processes is shown in Figure 6-1.
Figure 6-1 High-level design of the build and deployment processes for Java applications
The build process (see the left side of Figure 6-2 on page 131) uses the SCM build engine and the CICS build toolkit’s Build command to build the bundle directly within the build repository of zFS. The deployment process (see the right side of Figure 6-2 on page 131) uses the CICS build toolkit’s Resolve command to resolve different variables in the resource definitions (for example, the JVM server name attribute), and then uses the DFHDPLOY utility to deploy the bundle in CICS.
In this scenario, we use zFS as a readily available area in which to store built artifacts. However, because it is a simple file system, zFS does not offer features such as versioning, history, or atomic operations, which can make it harder to manage and result in additional work. Therefore, in the long term it might be more appropriate to use a purpose-built build repository such as Rational Asset Manager or Apache Archival. You can also use the IBM UrbanCode Deploy built-in build repository, which is called IBM UrbanCode Deploy CodeStation (in which case, it might be easier to use the IBM UrbanCode Deploy deployment processes rather than DFHDPLOY). If you use a purpose-built build repository, the process of adding and extracting artifacts is different from what we show in this chapter (specifically, you use the repository’s APIs rather than standard file system operations).
Figure 6-2 Build and deployment architecture for Java application development
6.2 General application description
The GENAPP Liberty Profile extension consists of three components:
•A web user interface (implemented with JSP technology)
•A servlet that is written in Java
•A COMMAREA wrapper that is written in Java
The web user interface is a JSP file that consists of one input field and an output table. In the input field, the user should enter a customer number. On submit, an HTTP POST request is sent with the customer number as a parameter. An output table is provided to display the search results from the HTTP response.
The servlet is a Java program that listens on the HTTP POST URL and then extracts the customer number from the request. The customer number is input into a COMMAREA that is sent as a JCICS link() parameter to a COBOL program of the GENAPP Base application. The program name in this case is LGICUS01.
The COMMAREA wrapper is a Java class that provides methods to interact with a byte array that represents the COMMAREA that is defined in the LGICUS01 copybook. The wrapper also handles data conversion between UTF-8 and EBCDIC.
Figure 6-3 is a diagram showing all of components that are used in the applications that are described in this chapter.
Figure 6-3 Liberty Extension for GENAPP application
6.3 JVM server configuration
Before you can deploy the web application, you must first define a JVM server in CICS, and a corresponding JVM profile. To create the JVM profile, you can use a modified version of the DFHWLP profile (see Example 6-1, which is provided with CICS Transaction Server (in <CICS_ROOT_DIR>/JVMProfiles/). This modified version is the version that we use to create the JVM server running in CICS Transaction Server.
Example 6-1 DFHWLP profile
#######################################################################
# JVM profile: DEVOPSLP #
# DEVOPS Liberty Profile #
#######################################################################
# #
# Licensed Materials - Property of IBM #
# #
# 5655-Y04 CICS Transaction Server #
# #
# (c) Copyright IBM Corporation 2012, 2015 All Rights Reserved #
# US Government Users Restricted Rights - Use, duplication #
# or disclosure restricted by GSA ADP Schedule Contract #
# with IBM Corporation #
# #
#######################################################################
#
# Symbol Substitution
# -------------------
#
# The following substitutions are supported:
# &USSHOME; => The value of the USSHOME SIT parameter.
# &CONFIGROOT; => the location of configuration files, such as the
# JVM profile.
# &APPLID; => The applid of the CICS region.
# &JVMSERVER; => The name of the JVMSERVER resource.
# &DATE; => Date the JVMSERVER is enabled (localtime). Dyymmdd
# &TIME; => Time the JVMSERVER is enabled (localtime). Thhmmss
#
# All variables must be delimited with & and ; for example
# ENV_VAR=myvar.&APPLID;.&JVMSERVER;.data
#
# Note: The continuation character for use with JVMProfiles is ''.
#**********************************************************************
#
# Required parameters
# -------------------
#
# JAVA_HOME specifies the location of the Java directory.
JAVA_HOME=/usr/lpp/java/J7.0_64/
#
# Set the current working directory.
WORK_DIR=/var/cicsts/devops/workdir
#
#**********************************************************************
#
# WebSphere Liberty Profile server (WLP)
# --------------------------------------
#
# To enable a Liberty (WLP) server.
WLP_INSTALL_DIR=&USSHOME;/wlp
#
# Optionally define the directory to store shared and server-specific
# configuration.
WLP_USER_DIR=./&APPLID;/&JVMSERVER;/wlp/usr
#
# Optionally define the directory to contain output files for defined
# servers.
WLP_OUTPUT_DIR=./&APPLID;/&JVMSERVER;/wlp/user/servers
#
# Instruct CICS to create and configure the WLP.
-Dcom.ibm.cics.jvmserver.wlp.autoconfigure=true
#
# Instruct CICS to set the port used for HTTP requests.
-Dcom.ibm.cics.jvmserver.wlp.server.http.port=53040
#
# Instruct CICS to set the port used for HTTPS requests.
-Dcom.ibm.cics.jvmserver.wlp.server.https.port=53041
#
# The following JVM options are optimized for generic Liberty workloads
# -Xms Initial Java heap size
# -Xmx Maximum Java heap size
# -Xmso Initial stack size for native threads (JVM default -Xmso256KB)
-Xms128M
-Xmx256M
-Xmso128K
#
# Set the Garbage collection Policy.
-Xgcpolicy:gencon
#
# The following option enables the "aggressive" level of Just-In-Time
# (JIT) optimization, exploiting the latest hardware optimizations
# available from the IBM 64-bit SDK for z/OS, Java Technology Edition.
#-Xaggressive
#
# Using a shared class cache
# --------------------------
# JVM servers within the same z/OS LPAR can use a common Java
# shared class cache. This reduces the overall virtual storage
# consumption, improves JITing and reduces JVM startup time. The
# following options create a 128 MB shared cache, which can be accessed
# by all CICS regions in the same RACF group.
-Xscmx128M
-Xshareclasses:name=cicsts530%g,groupAccess,nonfatal
#
-Dcom.ibm.tools.attach.enable=no
#
# WebSphere Application Server Liberty profile is only supported when
# running under a JVM with the UTF-8 or ISO-8859-1 character encodings.
-Dfile.encoding=ISO-8859-1
#
After you create the jvmprofile in a zFS directory, you should create a JVMSERVER resource definition in CICS that points to the location of the new profile. Make sure that the resource is installed and that the server is enabled.6.4 Importing the application source code and setting up CICS Explorer
To develop and deploy web applications, you must install the CICS SDK for Servlet and JSP support into CICS Explorer. The steps that are required to install the SDK depend on the method that you chose to install CICS Explorer. For more information, see Chapter 2, “Development environment” on page 11.
After installing the SDK, you can import the source code from the GENAPP Liberty extension that you downloaded by completing the following steps:
1. Switch to the Java perspective by clicking Window → Open perspective → Other, and then clicking Java (see Figure 6-4).
Figure 6-4 Final step of switching to the Java perspective
2. Import the predefined source code that you downloaded:
Figure 6-5 Import existing projects into the workspace
b. Select the folder that contains the downloaded GENAPP Liberty extension, choose the project to import, and click Finish (see Figure 6-6 on page 137).
Figure 6-6 Select a project to import
The imported project now is listed in the Package Explorer view.
6.5 Deploying the Liberty extension web application
|
Note: The GENAPP Liberty extension requires the GENAPP Base application. If you have not installed the GENAPP bAse application, do so before completing the steps in this section.
|
To deploy the Java application in CICS without using automated build and deploy processes, complete the following steps:
1. Create the CICS bundle project, which is exported to the zFS later, and refer to the web project that you already imported.
2. Export the CICS bundle project to a specific location on zFS.
3. Discard any prior versions of the CICS bundle resource (if any exist).
4. Create the CICS bundle definition that points to the new bundle directory (containing the latest version you want to deploy).
5. Install the new CICS bundle.
6. Check the Java application to confirm that it is working.
Based on the steps above, you can deploy the Liberty extension in CICS Transaction Server for the first time by completing the following steps:
1. Create a CICS bundle project:
Figure 6-7 CICS Bundle Project
b. Give the project a name and click Finish (see Figure 6-8). After you complete this step, the project should appear in the Package Explorer view of your workspace.
Figure 6-8 CICS Bundle Project attributes
2. Reference your CICS bundle to the web application project:
a. Open the cics.xml file (look in the META-INF directory in CICS bundle project that you created in step 1 on page 138). In the Defined Resources section, click New and select Dynamic Web Project Include (see Figure 6-9).
Figure 6-9 Add a reference to the web project
b. Select the imported project containing the web application and specify the JVM server name on which the application should run under CICS. Click Finish (see Figure 6-10).
|
Note: Section 6.6, “Creating an automated build and deployment process by using Rational Team Concert and the CICS build toolkit” on page 146 describes the use of variables instead of hardcoded values. Instead of writing GENALIBS as the JVM server name in this scenario, we use a variable that is to the correct value according to the environment to which it is being deployed.
|
Figure 6-10 Naming the JVM server on which the application will run
3. Export your CICS bundle project to the wanted location:
a. Right-click the CICS bundle project that you created and select Export Bundle Project to z/OS UNIX File System (see Figure 6-11).
Figure 6-11 Select the export destination
b. In the window that opens, select Export to a specific location in the file system.
c. Select the directory where you want the bundle definition stored and click Finish (see Figure 6-12 on page 143).
Figure 6-12 Select the folder where the bundle will be stored
4. Define and install the bundle resource definition within CICS:
a. Switch to the CICS SM perspective.
b. Open the bundle definition view and click Definitions → Bundle Definitions.
c. Initiate creation of the new bundle definition by clicking File → New → Other and then selecting Bundle Definition.
d. Define the bundle by specifying the CICSPlex name, region (if you want the bundle definition in your CSD), CSD group, bundle name, and the directory on zFS where the bundle exists (see Figure 6-13).
Figure 6-13 Define the CICS bundle
e. Install the bundle by right-clicking the bundle name and selecting Install. Then, select the CICS region in which to install the bundle and click OK. The bundle is now installed and enabled (to confirm, click Operations → Bundles to see the Bundle view (Figure 6-14).
Figure 6-14 Bundle view showing the newly enabled CICS bundle
The web application is now installed in the JVM server within CICS, demonstrating the successful use of the JCICS API and Liberty JVM server with CICS. The application is accessible from the following location and appears in your browser, as shown in Figure 6-15:
https://<your_MF_localhost>:<https_port_defined_in_JVMProfile>/Genapp_Customer_Search/
Figure 6-15 Browser view of the GENAPP Liberty extension web application
When you enter a Customer Number (for example, 1), and click Search, you see the output that is shown in Figure 6-16.
Figure 6-16 Customer search result details when searching for customer number 1
6.6 Creating an automated build and deployment process by using Rational Team Concert and the CICS build toolkit
The build and deploy process involves many manual activities. You must export the CICS bundle project to z/FS, copy the bundle to the correct location based on the environment to which you are deploying, create and install a CICS bundle resource definition that points to the directory of the newest version, and verify that the CICS bundle resource is enabled.
To achieve continuous integration and continuous deployment as addressed by DevOps methodology, you must create an automated build and deployment process. The automated build uses the CICS build toolkit to create deployable artifacts from the CICS bundle project. The automated deployment copies the zFS directory that contains the built bundle from the build process, resolves attribute variables (for example, the JVM server name), disables and discards the current CICS bundle resource, and creates and installs the new CICS bundle resource.
To demonstrate how automated build and deployment processes work, make a change in the application. In this example, the application outputs at table result of the customer details, as shown in Figure 6-17. The change that you make is to add another field, “Phone Mobile”, to the customer details result. By looking at the source code of GENAPP and its Liberty extension, you can tell that the information is already in the web application COMMAREA (see Group-Item CA-CUSTOMER-REQUEST in COPY-MEMBER LGCMAREA, and the InquiryCommarea Java class that is supplied with the Liberty extension).
Figure 6-17 Group definition for the inquiry results
As a result, the only thing that you must do is to add a fields definition that corresponds to the field in the COBOL COPY-MEMBER, and put these fields in the JSP file.
To make these changes, complete the following steps (all the changes are performed under the CICS Explorer IDE):
1. Add the mapping fields num_policies and phone_mobile to the Java program InquiryCommarea.java (see Figure 6-18 on page 147).
Figure 6-18 InquiryCommarea fields change
2. Add matching getter and setter methods to the phone_mobile field in the InquiryCommarea.java program (see Figure 6-19 and Figure 6-20).
Figure 6-19 Getter method for new phone_mobile field
Figure 6-20 Setter method for new phone_mobile field
Figure 6-21 Print the new phone_mobile field in the FetchData method
4. Change the version number in the cics.xml file in the CICS bundle project to 1.1.0 to indicate that this is the newer version of this application.
5. Use variable substitution to replace the hardcoded value for the JVM server name in the warbundle file:
a. Replace the value of the jvmserver attribute with the variable jvm.server.name. Variables are identified by ${xxx}, where the xxx between the brackets indicates the variable name (see Figure 6-22). The CICS build toolkit resolves the variable at the correct time.
Figure 6-22 Adding a variable to the warbundle file
b. Add a variables.properties file to the CICS bundle project. This file defines a default value for the variable (see Example 6-2).
Example 6-2 Variables.properties file in the bundle project provides a default value for the JVM server name
jvm.server.name=GENAJVM
c. Create a properties file for each environment to provide the variable value that applies there. When the variable is resolved, the value in the environment-specific properties overrides the default value that is provided in the bundle project variables.properties file (see Example 6-3 for an example properties file for a test environment). These files can be stored in a project in source code management (SCM) system alongside the application source, but must be made available on zFS at deployment time.
Example 6-3 Test.properties file provides a variable value for the test environment
jvm.server.name=TESTJVM
When the changes are completed, the next thing you must do is to build the application.
Here, you can enjoy the benefit of continuous integration. Instead of exporting the changes manually to the z/FS, you can use a build engine to start the CICS build toolkit to create the new bundles. The build engine in our example is Rational Team Concert Build with Ant integration, which you can use to run the cicsbt command to create the bundle in the build directory in z/FS.
For this example, you must create a similar definition based on the Ant – Jazz Build Engine template that is provided in Rational Team Concert. We schedule this build definition to run every 5 minutes. We use a build engine that is installed in z/OS so that we can build the bundle directory directly to z/FS. The properties for this build definition are shown in Table 6-1.
Table 6-1 Build definition properties
|
Name
|
Value
|
Use of property
|
|
ant.work.dir
|
workdir
|
Working directory for the Ant script
|
|
build.output.dir
|
/var/cicsts/devops/builds/genappweb
|
Output directory for the CICS build toolkit build command
|
|
bundle.name
|
Genapp_Cus_Srch_Web_bundle
|
Bundle name to build
|
|
load.dir
|
${ant.work.dir}/${source.dir}
|
Load directory to be use in Rational Team Concert build definition
|
|
source.component
|
GENAPP Customer Search (Liberty)
|
Source component in Rational Team Concert
|
|
source.dir
|
source
|
The name of the source directory for the CICS build toolkit build command
|
|
target.platform
|
com.ibm.cics.explorer.sdk.web.liberty53.target
|
The name of the target platform for the CICS build toolkit build command
|
In this example, we use an Ant build script to run the cicsbt_zos command in z/OS.
After we create the build definition, we request a build so that Rational Team Concert builds the bundle in the correct z/FS build output directory (/var/cicsts/devops/builds/genappweb). The suggested structure is to have a subdirectory for each logical application. In this case, the directory contains the Genapp_Cus_Srch_Web_Bundle_1.0.0/ bundle directory that has the WAR file warbundle file, and the cics.xml file (see Figure 6-23).
Figure 6-23 Bundle that is built by the build definition
6.7 Deploying the build
Next, deploy the bundle to an appropriate bundle directory (for example, the one in your test environment), create a CICS bundle definition, and install it. This example assumes that you have a previous version of the bundle that is installed with a lower semantic version.
For these processes, use the new DFHDPLOY utility in CICS Transaction Server V5.3, which you can use to define, install, discard, and set the availability status of bundles. The DFHDPLOY utility can be started from JCL and integrated with your existing deployment and automation procedures. Use z/OS commands to copy zFS directories and the CICS build toolkit to resolve variables in the bundle.
Complete the following steps:
1. Copy the specific bundle directory that you want to deploy to a temporary work directory. This step is important because when you use the CICS build toolkit resolve command, it resolves all the bundles in the input directory, and you want to resolve only a specific bundle. For this step, use the BPXBATCH utility, which you can use to issue SHELL scripts or UNIX programs.
2. Clean the work directory that you will use for the resolved bundle.
3. Resolve the variables in the bundle by running the CICS build toolkit resolve command. After you run this command, the bundle is in a work directory, which ensures that if the resolve step fails, the existing target directory remains intact. Use an environment-specific properties file to provide the appropriate value for the JVM server name.
4. Copy the resolved bundle to the target directory if the resolve step succeeds. This is the directory from which you install the bundle definition, and it depends on the environment to which you are deploying.
5. Use the DFHDPLOY utility to make two changes:
a. Undeploy the current bundle.
b. Deploy the new bundle from the appropriate bundle directory and enable it.
If you have multiple bundles to deploy, you need to perform several instances of this step.
DFHDPLOY takes care of discarding the old CSD definition for the BUNDLE resource and creating the new one in the specified group. Because your are deploying a new version of an existing bundle, assume that the CSD group is added to an appropriate group list to ensure that the bundle is installed on a cold start of the CICS system. When you deploy a bundle to a group that has not been used before, you can add a step that calls the DFHCSDUP utility to add the group to a list. In general, your deployment script should be robust enough to be rerun if there is a failure, for example, if the set of CICS regions in the scope change during the course of deployment.
It is important to understand that this deployment process results in a short loss of service for the application. This loss occurs in the short time frame from when you undeploy the old version of the bundle until the new version of the bundle is enabled. If clients attempt to access the web page during this time, they get an HTTP 404 Not Found response.
If you must deploy a web application with no outage, you can create a version of the application with a different URI for the context root. You can then deploy the new bundle alongside the old version, and use the new URI to reach the new version. Later, you can undeploy the old version. For this method to work, you must use two different names for the BUNDLE resource, rather than the same name described above. For more information about processes for lifecycling and versioning web applications, see CICS and Liberty: What You Need to Know, SG24-8335.
Another consideration when this process is applied to production deployments is quiescing the workload. Before undeploying any version of a web application, you should allow workload to drain away. For example, if you have a load balancing configuration, you can temporarily direct work away from the systems where the deployment occurs. When the bundle is disabled, any in-flight work completes, but any new requests fail.
Example 6-4 shows the JCL that is used to complete the steps that were described. The example uses symbols in in-stream data, which was first supported in
z/OS V2.1. If you are running an earlier version of z/OS, you must modify the example as needed.
z/OS V2.1. If you are running an earlier version of z/OS, you must modify the example as needed.
Example 6-4 Deploy a JCL by using the DFHDPLOY utility
//GENADPLY JOB CLASS=A,MSGCLASS=A,NOTIFY=&SYSUID
//*
//EXPORT EXPORT SYMLIST=*
//*
// SET CPSMHLQ=CICSDPP.BETA14.CTS53BT.CPSM
// SET CICSHLQ=CICSDPP.BETA14.CTS53BT.CICS
// SET CICSPLEX=CICSPLEX
// SET JAVAHOME='/java/J8.0_64/'
// SET BUNWRKDR='/var/cicsts/devops/workdir'
// SET BUNBLDDR='/var/cicsts/devops/builds/bundles'
// SET PROPSDIR='/var/cicsts/devops/properties'
// SET ENVNAME='test'
// SET TARGETDR='/var/cicsts/TESTPLEX'
// SET BUNDNAME='Genapp_Cus_Srch_Web_bundle_1.1.0'
// SET CICSBTCM='/usr/lpp/cicsts/cicsbt/cicsbt/cicsbt_zos'
//*
// SET CIBUNDNM=GENACWSB
// SET CISCOPE=CICSDA01
// SET CSDGROUP=GENAWEB
//*
//* First step is to clean up the work directory
//*
//CLEAN EXEC PGM=BPXBATCH,REGION=0M,MEMLIMIT=6G
//STEPLIB DD DSN=CEE.SCEERUN,DISP=SHR
//STDOUT DD SYSOUT=*
//STDERR DD SYSOUT=*
//STDENV DD *,SYMBOLS=JCLONLY
JAVA_HOME=&JAVAHOME
/*
//STDPARM DD *,SYMBOLS=JCLONLY
SH
rm -r &BUNWRKDR/*;
//*
//* Second step is to resolve the bundle using cicsbt_zos
//*
//RESOLVE EXEC PGM=BPXBATCH,REGION=0M,MEMLIMIT=6G
//STEPLIB DD DSN=CEE.SCEERUN,DISP=SHR
//STDOUT DD SYSOUT=*
//STDERR DD SYSOUT=*
//STDENV DD *,SYMBOLS=JCLONLY
JAVA_HOME=&JAVAHOME
/*
//STDPARM DD *,SYMBOLS=JCLONLY
PGM
&CICSBTCM
--resolve &BUNBLDDR
--output &BUNWRKDR
--properties &PROPSDIR/&ENVNAME..properties
--verbose
//*
//* Third step is to copy the resolved output to the target dir
//*
//COPY EXEC PGM=BPXBATCH,REGION=0M,MEMLIMIT=6G,COND=(0,NE,RESOLVE)
//STEPLIB DD DSN=CEE.SCEERUN,DISP=SHR
//STDOUT DD SYSOUT=*
//STDERR DD SYSOUT=*
//STDENV DD *,SYMBOLS=JCLONLY
JAVA_HOME=&JAVAHOME
/*
//STDPARM DD *,SYMBOLS=JCLONLY
SH
cp -r
&BUNWRKDR/*
&TARGETDR
//*
//* Final step is UNDEPLOY the old bundle
//* then DEPLOY and set available the new bundle
//*
//DFHDPLOY EXEC PGM=DFHDPLOY,REGION=100M,COND=(0,NE,COPY)
//*
//STEPLIB DD DISP=SHR,DSN=&CPSMHLQ..SEYUAUTH
// DD DISP=SHR,DSN=&CICSHLQ..SDFHLOAD
//*
//SYSTSPRT DD SYSOUT=*
//*
//SYSIN DD *,SYMBOLS=JCLONLY
*
SET CICSPLEX(&CICSPLEX);
UNDEPLOY BUNDLE(&CIBUNDNM)
SCOPE(&CISCOPE)
CSDGROUP(&CSDGROUP)
STATE(DISCARDED);
*
* Define a CICS bundle resource and move it towards an
* ENABLED state within the current CICSplex.
*
*
DEPLOY BUNDLE(&CIBUNDNM)
SCOPE(&CISCOPE)
CSDGROUP(&CSDGROUP)
BUNDLEDIR(&TARGETDR/bundles/&BUNDNAME/)
STATE(ENABLED);
/*
|
Note: The JCL that is shown in Example 6-4 on page 151 is fully parameterized and can be easily modified for different environments and bundles. It can also be a baseline for automatically generated JCLs. The final steps run only if the previous step succeeded.
|
Table 6-2 provides details about the steps that are involved in the JCL that is shown in Example 6-4 on page 151.
Table 6-2 JCL steps that are involved in Example 2
|
Step
|
Description
|
|
CLEAN
|
Deletes the contents of the work directory /var/cicsts/devops/workdir/.
|
|
RESOLVE
|
Resolves the bundle, by using the CICS build toolkit, to the work directory (in this case, /var/cicsts/devops/workdir) with the appropriate properties files for the environment (in this case, /var/cicsts/devops/properties/test.properties).
|
|
COPY
|
Copies the resolved bundle from the work directory to the target location
(/var/cicsts/devops/workdir to /var/cicsts/CICSPLEX) by running the cp command.
|
|
DFHDPLOY
|
Undeploys the current bundle (disables and discards the resource and then deletes the definition from the CSD) and deploys the new bundle (points to the new bundle directory, Version 1.1.0).
|
After submitting the JCL, the changes should be applied to the application and the result should be as shown in Figure 6-24.
Figure 6-24 Web application after the change was applied (Version 1.1.0)
Here is a summary of what was done in this chapter:
1. Installed the first version of the example application with no automatic build or deployment process. Everything was done manually (exporting the bundle, disabling and discarding the CICS bundle resource, defining a CICS bundle with the appropriate zFS directory, and installing the bundle in the wanted CICS region).
2. Created a build definition that integrates the Rational Team Concert Build engine, Ant build script, and CICS build toolkit’s build command to build the wanted bundle in a zFS directory.
3. Created a deployment process that uses the CICS build toolkit’s resolve command to resolve variables within resource definition attributes, undeploys the CICS bundle resource definition, defines the CICS bundle with the newer version of the deployed bundle, and installs it in the target environment.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.