Integral Code Extension Framework

Version 3.0

Dated 2017-12-07

DXC’s Integral

DXC has prepared this document in good faith. Many factors outside DXC’s current knowledge or control
affect the recipient’s needs and project plans and errors in the document will be corrected by DXC. The
responsibility lies with the recipient to evaluate the document for applicability.

The information in the document is proprietary, confidential and an unpublished work and is provided
upon recipient’s covenant to keep such information confidential. Personal data supplied in this document
may not be used for any purpose other than for which it was supplied. Personal Data may not be
transferred to other parties without the prior consent of DXC. In no event may this information be
supplied to third parties without DXC’s consent.

The following notice shall be reproduced on any copies permitted to be made:

©Copyright DXC Technology. All rights reserved.

Integral Code Extension Framework Version 3.0

REVISION HISTORY

Version Date Revision Description Revised by

1.0 2017-05- Initial Version Vivek Agrawal

11
2.0 2017-05- Updated document for package naming Vivek Agrawal
25 guideline, [Link] creation guideline and
added details on how Sxxxx Form JSP
location is derived from SxxxxScreenVars
package name.
3.0 2017-12- Added indicators reservation and data Vivek Agrawal
07 modeling suggestion

Page 2 of 45
Integral Code Extension Framework: DXC’s Integral
Integral Code Extension Framework Version 3.0

TABLE OF CONTENTS
1 INTRODUCTION ................................................................................................................ 6
1.1 SCOPE.......................................................................................................................................... 7

2 CODE EXTENSION SERVICE DESIGN ............................................................................. 7

2.1 ARCHITECTURE DIAGRAM .............................................................................................................. 7
2.2 COMPONENT DETAILS ................................................................................................................... 8
2.2.1 Code Extension Service Package ................................................................................... 8
[Link] Introduction ...................................................................................................... 8
[Link] GitHub Structure .............................................................................................. 8
2.2.2 Customer package .......................................................................................................... 9
[Link] Introduction ...................................................................................................... 9
[Link] GitHub Structure ............................................................................................ 10

3 TECHNICAL DETAILS – CODE EXTENSION SERVICE PACKAGE .............................. 10

3.1 INTEGRALAFEXTENSION.............................................................................................................. 10
3.1.1 Maven Configuration ..................................................................................................... 10
3.1.2 Spring Configuration ([Link]) ............................................................ 11
3.2 INTEGRALFSUEXTENSION ............................................................................................................ 11
3.2.1 Maven Configuration ..................................................................................................... 11
3.2.2 Spring Configuration ([Link]) ........................................................... 11
3.2.3 AppLocator .................................................................................................................... 11
3.3 INTEGRALLIFEEXTENSION ............................................................................................................ 12
3.3.1 Maven Configuration ..................................................................................................... 12
3.3.2 Spring Configuration ([Link]) ........................................................... 12
3.4 INTEGRALPOLISYEXTENSION ....................................................................................................... 12
3.4.1 Maven Configuration ..................................................................................................... 12
3.4.2 Spring Configuration ([Link]) ...................................................... 13
3.5 INTEGRALGROUPEXTENSION ....................................................................................................... 13
3.5.1 Maven Configuration ..................................................................................................... 13
3.5.2 Spring Configuration ([Link]) ...................................................... 13
3.6 SPRING CONFIGURATION RELATION ............................................................................................. 14

4 TECHNICAL DETAILS – CUSTOMER PACKAGE .......................................................... 14

4.1 CUSTOMERAAAPP ...................................................................................................................... 14
4.1.1 Maven Configuration ..................................................................................................... 15
4.1.2 Spring Configuration ..................................................................................................... 15
4.1.3 Customer specific AppLocator (xxxxAppLocator) ......................................................... 17
4.2 CUSTOMERAAW EB ..................................................................................................................... 18
4.2.1 Maven Configuration ..................................................................................................... 18
4.2.2 [Link] configuration ................................................................................................... 19

5 IMPORTANT GUIDELINES .............................................................................................. 19

5.1 PACKAGE NAME SHOULD START WITH [Link] ............................................................................ 19
5.2 DETERMINING JSP FILES PATH..................................................................................................... 19
5.3 CHANGE REQUIRED FOR BATCHES ............................................................................................... 20
5.3.1 [Link] (CSCSmart400Batch) ..................................................................................... 20
Page 3 of 45
Integral Code Extension Framework: DXC’s Integral
Integral Code Extension Framework Version 3.0

5.3.2 Passing [Link] to BatchServerLauncher ........................................ 20

5.4 ADD CUSTOMER PACKAGES TO ROOT POM FOR BUILD .................................................................... 21
5.4.1 Modify root [Link] ...................................................................................................... 21
5.4.2 Maven Build Command ................................................................................................. 22
5.5 W [Link] CHANGE IN CUSTOMER W AR ......................................................................................... 22
5.6 RESOURCE BUNDLE HANDLING IN CUSTOMER PACKAGE ................................................................ 22
5.7 HANDLING [Link] ............................................................................................................. 22
5.8 HANDLING [Link] ................................................................................................................. 23
5.9 HOW TO HANDLE DB OPERATIONS .............................................................................................. 23
5.9.1 Existing DB table ........................................................................................................... 23
[Link] Customer wants to use existing DB table structure ...................................... 24
[Link] Customer wants to change DB table structure .............................................. 24
5.9.2 New DB table ................................................................................................................ 24

6 CREATING A NEW TRANSACTION IN CUSTOMER PACKAGE – IMPLEMENTATION

DETAILS .................................................................................................................................. 24
6.1 CSCINTEGRALEXTENSION........................................................................................................... 24
6.2 CUSTOMERAAAPP ...................................................................................................................... 25
6.3 CUSTOMERAAW EB ..................................................................................................................... 25
6.4 EXAMPLE – CLIENT EMPLOYMENT DETAILS................................................................................... 25
6.4.1 Create Employment Details .......................................................................................... 26
6.4.2 Modify Employment Details........................................................................................... 28
6.4.3 Inquire Employment Details .......................................................................................... 29
6.5 CODE CHANGES.......................................................................................................................... 30

7 CREATING A NEW BATCH PROGRAM IN CUSTOMER PACKAGE –

IMPLEMENTATION DETAILS .................................................................................................. 30
7.1 CODE CHANGES.......................................................................................................................... 31
7.1.1 CSCFsuApp .................................................................................................................. 31
7.1.2 IntegralFsuExtension .................................................................................................... 32
7.1.3 CustomerAAApp ........................................................................................................... 33

8 MODIFY EXISTING SCREEN/TRANSACTION– IMPLEMENTATION DETAILS ............. 34

8.1 INTRODUCTION ............................................................................................................................ 34
8.2 STEPS ........................................................................................................................................ 34
8.2.1 Modify [Link] ............................................................................................... 35
8.2.2 Modify [Link] .............................................................................................. 37
8.2.3 Modify [Link] ........................................................................................... 37
8.2.4 Modify [Link] ........................................................................................... 39
[Link] write() ............................................................................................................. 39
[Link] update() ......................................................................................................... 40
[Link] readNextChangedRecord() ........................................................................... 40
[Link] chain() ............................................................................................................ 41
[Link] set1stScreenRow() ........................................................................................ 41
[Link] setNextScreenRow() ..................................................................................... 42
[Link] clearFormatting() ........................................................................................... 42
8.2.5 Modify [Link]....................................................................................... 42
8.2.6 Modify [Link] ......................................................................................................... 43
8.2.7 Write [Link] (in Customer package) ................................................................. 44
Page 4 of 45
Integral Code Extension Framework: DXC’s Integral
Integral Code Extension Framework Version 3.0

8.2.8 Registering [Link] as Spring bean ................................................................... 44

8.2.9 Write [Link] (in Customer package) .............................................. 44
8.2.10 Copy [Link] and [Link] in Customer package .......................................... 44
8.2.11 Write subroutines in Customer Package ....................................................................... 45
8.3 CODE DETAILS ............................................................................................................................ 45

Page 5 of 45
Integral Code Extension Framework: DXC’s Integral
Integral Code Extension Framework Version 3.0

1 INTRODUCTION
As we have decided to do all the development in single code base, there is requirement on how
would customer do their own development without impacting our Integral BASE. Currently we
don’t have such ability in Integral.

Code Extension approach provides a way to customer to do their own development in customer
package. Overall, there are two aspects of code extension approach:
1. Development in customer package using Code Extension Service Package
2. Development in customer package using Code Extension Service Package and Code
Extension Points

As far as customer’s own development is concerned, there could be following scenarios:

1. Customer may create a new Transaction or may create a new batch –

Development using Code Extension Service Package
This is scenario, where customer wants to create a new transaction with new screens. In
Integral, new transaction/screen needs Pxxxx programs and screen related files, which
will be created in customer package, outside Integral BASE.

Customer may also want to develop new batches, which requires creating new Bxxxx
programs in Integral. For new batches, customer will create new Bxxxx programs in
customer package.

For DB operation (in both online transaction and batches), customer will create
service/DAO in either Integral Base (DAO is created using DAO guideline in Integral
Base and Service over DAO will be created in Code Extension Service Package) or
Customer package itself, depending upon conditions described later in document. As
Code Extension Service Package is part of Integral BASE, project development team
from DXC will create service/DAO for customer here.

2. Customer may ask DXC to modify existing transaction or may want to

inject their own developed functionality in integral – Development using
Code Extension Service Package and Code Extension Points
This is scenario, where customer asks DXC to modify existing transaction or wants to
inject their own developed functionality (developed in Customer Package, outside
Integral base) in Integral.

As far as existing transaction modification is concerned, customer will come to DXC first.
DXC project team will provide code extension points to customer. In this scenario,
existing Pxxxx programs will be extended in customer package using inheritance along
with other required files. In parent Pxxxx programs, we will define injection points (i.e.
default methods), where customer wants to inject code. In extended Pxxxs programs,
they will override those methods to inject customer specific code.

Similarly, when customer wants to inject their own developed functionality in Integral,
they will come to DXC first to provide proper code injection points. For example,
customer wants to call an external work flow system when there is an error in issuing a

Page 6 of 45
Integral Code Extension Framework: DXC’s Integral
 Integral Code Extension Framework Version 3.0

NB policy. At present, we do not have such capability, but a customer may ask for that.
So, we need to define extension points in Integral base for the same. The normal
injection code supplied in Integral base is normally a default method. Customer can
then inject their own code to such extension point to replace such default method to
carry out whatever processing customer required.

1.1 SCOPE
This document covers how customer can do development in customer package using Code
Extension Service Package and Code Extension Points.

2 CODE EXTENSION SERVICE DESIGN

2.1 ARCHITECTURE DIAGRAM

Integral BASE Package

[Link]

Customer Package [Link]

[Link] [Link]
CustomerAAApp CustomerAAWeb

[Link] [Link]

Code Extension Service

[Link]
Package

Other Jars

For PNC, there is [Link] and for

Group, there is [Link]

Page 7 of 45
Integral Code Extension Framework: DXC’s Integral
Integral Code Extension Framework Version 3.0

2.2 COMPONENT DETAILS

As shown in architecture diagram, there are two main components:

2.2.1 Code Extension Service Package

[Link] Introduction
This package will contain services to interact with Integral system. The reason for such
extension package is to isolate the base code from the customer code so that the
customer code is less affected when we change our base code.
For modularity and flexibility, this package is divided into two main categories:
Common packages
This category contains two packages:
- IntegralAFExtension
This package contains IAF (IntegralAdminFramework) specific services.
- IntegralFsuExtension
This package contains FSU specific services.

LOB specific packages

This category contains following packages:
- IntegralLifeExtension
This package contains Life specific services.
- IntegralPolisyExtension
This package contains Polisy specific services.
- IntegralGroupExtension
This package contains Group specific services.

[Link] GitHub Structure

On GitHub, Code Extension Package is distributed in following way. We have
CSCIntegralExtension repository, which contains two packages –
IntegralAFExtension and IntegralFSUExtension. For each LOB, we have different
GitHub repository, each LOB contains LOB specific package i.e.
IntegralLife(Polisy/Group)Extension.
CSCIntegralExtension repository is added as GIT submodule in each LOB specific
repository, which brings IntegralAFExtension and IntegralFSUExtension into LOB
specific repositories.

Page 8 of 45
Integral Code Extension Framework: DXC’s Integral
Integral Code Extension Framework Version 3.0

CSCIntegralExtension Repo

IntegralAF Extension

IntegralFSUExtension

CSCIntegralExtension GitHub Repository

This GIT submodule brings IntegralAFExtension and IntegralFSUExtension from CSCIntegralExtension

repository

PNC Repo Life Repo Group Repo

CSCIntegralExtension CSCIntegralExtension CSCIntegralExtension

Submodule Submodule Submodule

IntegralLifeExtension IntegralGroupExtension
IntegralPNCExtension

PNC, Life and Group GitHub Repositories

2.2.2 Customer package

[Link] Introduction
Note: For our case, we assumed that customer is Life customer and customer name is
CustomerAA.

Basically, there will be two modules for customer package:

- Jar Module (CustomerAAApp)

Page 9 of 45
Integral Code Extension Framework: DXC’s Integral
Integral Code Extension Framework Version 3.0

It is similar to CSCLifeAsiaApp/CSCPolisyAsiaApp/CSCGroupAsiaApp. It will hold

Pxxxx programs, screen relates files, DAOs and Services for customer specific
tables etc.
- War Module (CustomerAAWeb)
This module will hold customer JSP files, customer specific [Link], customer
specific [Link], customer specific resource bundles etc. This customer war will
be deployed independently. Here maven war overlay concept is used in such a way
that Integral BASE war i.e. CSCLifeAsiaWeb will explode into customer war i.e.
CustomerAAWeb. When overlay happens, it copies resources from Integral BASE
war into CustomerAAWeb. If there are any conflicting resources, maven overlay will
retain resources from CustomerAAWeb and ignore resources from Integral BASE
war i.e. CSCLifeAsiaWeb.

[Link] GitHub Structure

Customer specific package will reside in separate GitHub repository. In our example
both CustomerAAApp and CustomerAAWeb packages reside in CustomerAA GitHub
repository. For every customer, there will be different GitHub repository.
This customer specific repository can be added as GIT submodule into main project
repository. This way when developer will clone main project repository, customer
specific packages will also get cloned. This way customer specific packages will build
along with main project using maven. This is one option.
Another option is that we don’t add customer specific repository as GIT submodule into
main project. Developers can clone both main project repository and customer specific
repository individually. This is second option and more recommended, because this
avoid adding GIT submodule for each customer in main project repository. As far as
running build on BnD side is concerned, they use Jenkins and they can configure
Jenkins to point to correct GitHub repository.

3 TECHNICAL DETAILS – CODE EXTENSION SERVICE

PACKAGE
This package has following roles:
1. This package will have services to handle DB operations
2. This package will act as interface to interact with Integral

This packages is divided into five packages as described in previous section. Technical
details are as follows

3.1 INTEGRALAFEXTENSION
This package contains IAF (IntegralAdminFramework) specific services.

3.1.1 Maven Configuration

This package has dependency over IAF.

Page 10 of 45
Integral Code Extension Framework: DXC’s Integral
Integral Code Extension Framework Version 3.0

3.1.2 Spring Configuration ([Link])

This will contain bean definitions for services specific to IntegralAdminFramework.

3.2 INTEGRALFSUEXTENSION
This package contains FSU specific services. It also contains AppLocator, which is talked
about in detail later.

3.2.1 Maven Configuration

This package has dependency over IntegralAFExtension and CSCFsuApp.

3.2.2 Spring Configuration ([Link])

This will contain bean definitions for services specific to FSU and imports integral-
[Link] as resource.

3.2.3 AppLocator
In Integral Java, for programs to be called, their locations are to be stored in *.path files.
For example, for CSCLifeAsiaApp, there is [Link] and
[Link]. Similarly, customers will be required to have their own XXXXAppLocator
and [Link] files. AppLocator will work as an interface between customer package
and Integral.
It has one method
- locate()

Page 11 of 45
Integral Code Extension Framework: DXC’s Integral
Integral Code Extension Framework Version 3.0

This method will take customer package .path file as InputStream and add customer
specific programs locations to existing list, so that customer specific programs can
be called.

3.3 INTEGRALLIFEEXTENSION
This package contains Life specific services.

3.3.1 Maven Configuration

This package has dependency over IntegralFsuExtension and CSCLifeAsiaApp.

3.3.2 Spring Configuration ([Link])

This will contain bean definitions for services specific to Life and imports integral-fsu-
[Link] as resource.

3.4 INTEGRALPOLISYEXTENSION
This package contains Polisy specific services.

3.4.1 Maven Configuration

This package has dependency over IntegralFsuExtension and CSCPolisyAsiaApp.
Page 12 of 45
Integral Code Extension Framework: DXC’s Integral
Integral Code Extension Framework Version 3.0

3.4.2 Spring Configuration ([Link])

This will contain bean definitions for services specific to Polisy and imports integral-
[Link] as resource.

3.5 INTEGRALGROUPEXTENSION
This package contains Group specific services.

3.5.1 Maven Configuration

This package has dependency over IntegralFsuExtension and CSCGroupAsiaApp.

3.5.2 Spring Configuration ([Link])

This will contain bean definitions for services specific to Group and imports integral-
[Link] as resource.

Page 13 of 45
Integral Code Extension Framework: DXC’s Integral
Integral Code Extension Framework Version 3.0

3.6 SPRING CONFIGURATION RELATION

Spring configuration files for IntegralAFExtension, IntegralFSUExtension,
IntegralLifeExtension, IntegralPolisyExtension and IntegralGroupExtension are related in
following way.

[Link]

[Link]

[Link] [Link] [Link]

4 TECHNICAL DETAILS – CUSTOMER PACKAGE

This section talks about technical details of customer package. Customer development team
can use it as reference.

Note: We are using CustomerAAApp and CustomerAAWeb as reference implementations. It

doesn’t mean that every customer will put their code here. Each customer will create its own
xxxxApp and xxxxWeb modules and will put them in its own GitHub repository. Naming
convention is up to customer.

As discussed previously, we will have jar and war modules for each customer. Suppose if
customer is CustomerAA, modules would be:

4.1 CUSTOMERAAAPP
This package contains:
- Pxxxx, SxxxxScreenVars, Sxxxxscreen, Sxxxxprotect, [Link] required for new screen
- Extended Pxxxx, SxxxxScreenVars, Sxxxxscreen and Sxxxxprotect; and [Link] for
modifying existing transaction.
- DAO and Service layer for customer specific database tables and existing database tables
(if customer changes structure of existing database tables)
- Customer specific xxxxAppLocator i.e. CustomerAAAppLocator.

Note: [Link] files customer should put in one folder in src/main/resources in customer
specific jar package and they should define this folder name in <SubFolders> tag at first place in
[Link]. Reason for this is, Integral finds [Link] files in folders in <SubFolders> tag
in the order in which they are defined.
Page 14 of 45
Integral Code Extension Framework: DXC’s Integral
Integral Code Extension Framework Version 3.0

In our reference implementation, we have put [Link] files in customeraa folder and defined it
in <SubFolders> tag at first place in [Link]

[Link] configuration
<SubFolders>customeraa/fsu/life/iaf/diary/common</SubFolders>

CustomerAAApp snapshot

4.1.1 Maven Configuration

For this reference implementation, we assumed the customer is Life customer. It will have
dependency on IntegralLifeExtension. (For PNC customer dependency will be on
InetgralPolisyExtension and for Group customer dependency will be on
IntegralGroupExtension).

4.1.2 Spring Configuration

This package contains:

1. [Link]
This XML contains beans for framework related beans like applicator for customer i.e.
CustomerAAAppLocator. In this spring configuration, we imported integral-life-
[Link] from IntegralLifeExtension.

Page 15 of 45
Integral Code Extension Framework: DXC’s Integral
Integral Code Extension Framework Version 3.0

2. [Link]
This XML contains beans for new DAOs generated for customer table. In this spring
configuration, we imported [Link].

3. [Link]
This XML contains beans for new services generated for customer tables. In this spring
configuration, we imported [Link].

Note: In reference implementation, we created different xml files for spring configuration i.e.
[Link], [Link], [Link] and used ‘import
resource’ concept to link them. This is to avoid putting all the bean definitions in single xml file.

Every Life, PNC and Group customer should import integral-life-services (from
IntegralLifeExtension), integral-polisy-services (from IntegralPolisyExtension) and integral-
group-services (from IntegralGroupExtension) respectively. In reference example, customerAA-
[Link] is first xml in hierarchy, so it imports integral-life-services.

Following diagram shows how spring files are related.

Page 16 of 45
Integral Code Extension Framework: DXC’s Integral
 Integral Code Extension Framework Version 3.0

[Link] [Link] [Link]

[Link] [Link]
[Link]

[Link] [Link]
[Link]

[Link] [Link]
[Link]

CustomerAA (Life Customer) CustomerBB (PNC Customer) CustomerCC (Group Customer)

[Link]

[Link]

[Link]

CustomerDD (Life Customer)

4.1.3 Customer specific AppLocator (xxxxAppLocator)

Every customer should create customer specific AppLocator in this package and it will
be defined as bean (with lazy-init property set to false) in customer specific spring
configuration file. Also, customer will have to create *.path file, where packages will be
defined.
In our case, we have created CustomerAAAppLocator and it is defined in customerAA-
[Link] file. This CustomerAAAppLocator will call [Link]() method.
For storing packages path, we have created [Link] file.
Below snap shots show reference implementation.

Page 17 of 45
Integral Code Extension Framework: DXC’s Integral
Integral Code Extension Framework Version 3.0

[Link]

CustomerAAAppLocator bean definition in [Link]

[Link]

4.2 CUSTOMERAAWEB
It contains
- Customer developed JSP files for new and existing transactions.
- Customer specific [Link]
- Customer specific [Link]
- Customer specific resource bundles (properties files)

4.2.1 Maven Configuration

This package has dependency on IAF, CustomerAAApp and CSCLifeAsiaWeb.

For customer war module, concept of war overlay is used using maven. At runtime during
maven build, Integral BASE war (CSCLifeAsiaWeb in our case) will explode into Customer war
i.e. CustomerAAWeb. This war will be deployed as final war.

Page 18 of 45
Integral Code Extension Framework: DXC’s Integral
Integral Code Extension Framework Version 3.0

4.2.2 [Link] configuration

Customer will create [Link] inside CustomerAAWeb. Initially, we will copy [Link] content
from Integral Base to customer [Link]. Customer can make modifications in it.
Customer should define customer specific spring configuration file in [Link] as context param
value for contextConfigLocation context parameter. This way spring will be able to recognize
customer specific beans.
In our reference implementation, we just need to pass [Link].

5 IMPORTANT GUIDELINES
So far we discussed about the structure of Code Extension Service Package and
customer package. By referring previous section 4, customer can create packages they
need. This section talks about what other things customer needs to take care of after
creating customer specific package.

5.1 PACKAGE NAME SHOULD START WITH [Link]

Customers should start their package name with [Link]. This is required to generate
logs for customer specific classes.

5.2 DETERMINING JSP FILES PATH

In Integral, there is a relation between package name of SxxxxScreenVars and
[Link] file location. For example if SxxxxScreenVars package name is
[Link], [Link] file location should be /fsu/clients/eng in
webapp in web module.
Logic is, Integral consider the words separated by dot(.) between [Link] and screens
from package name, excludes [Link] and screens and append eng in the end. (Note:
This logic is written in [Link], if you want to check)

[Link] Package name

/fsu/clients/eng/[Link] JSP location

Page 19 of 45
Integral Code Extension Framework: DXC’s Integral
Integral Code Extension Framework Version 3.0

Let’s say, customer specific SxxxxScreenVars has package name as

[Link]. So, JSP path will be
/customeraa/life/anticipatedendowment/eng as shown below:

5.3 CHANGE REQUIRED FOR BATCHES

To create new batch programs in customer package, it will be required to add profile
based maven dependency of customer specific jar in CSCSmart400Batch. Here we will
allow customer to pass customer specific spring configuration file as command line
parameter to BatchServerLauncher (for this we have modified BatchServerLauncher),
when batch server starts.
In this reference implementation, we will add dependency of CustomerAAApp using profile
CustomerAA and will pass [Link] to BatchServerLauncher.

5.3.1 [Link] (CSCSmart400Batch)

5.3.2 Passing [Link] to BatchServerLauncher

Page 20 of 45
Integral Code Extension Framework: DXC’s Integral
Integral Code Extension Framework Version 3.0

5.4 ADD CUSTOMER PACKAGES TO ROOT POM FOR BUILD

To build customer specific packages along with Integral BASE, it is required to add
customer specific packages to root pom. We will use maven profiling to add these
projects, so that BASE is not impacted. When it is required to build specific to customer, it
is just required to pass profile in maven build.

5.4.1 Modify root [Link]

As shown in snapshot below, we added CustomerAA profile to add CustomerAAApp and
CustomerAAWeb.

Page 21 of 45
Integral Code Extension Framework: DXC’s Integral
Integral Code Extension Framework Version 3.0

5.4.2 Maven Build Command

Following maven build command can be used:
mvn -P CustomerAA clean -P CustomerAA install

5.5 [Link] CHANGE IN CUSTOMER WAR

As described in section 4.2.2, customer will copy [Link] content from Integral Base
[Link] to customer war (in our case it is CustomerAAWeb). Customer will need to pass
customer specific spring configuration file as described in 4.2.2.
During maven war overlay, it will consider customer [Link] and ignore base [Link].

5.6 RESOURCE BUNDLE HANDLING IN CUSTOMER PACKAGE

Customer would want to create new labels and/or modify existing labels.
ResourceBundleHandler is used to handle labels (i.e. properties file). Customer would
need to copy existing properties files and put them in Customer war package. Customer
can do whatever changes they want then. Maven war overlay will consider customer
specific properties files and ignore base properties files.
In our reference implementation, we have copied Integral_Life_en_US.properties file
from LifeAsiaWeb and put in CustomerAAWeb. We just added one properties file to show
how it works, you could copy what all you require.

5.7 HANDLING [Link]

Customer can copy [Link] from Integral BASE war and copy to Customer war.
Maven war overlay will consider customer [Link]. In our reference implementation,
we have put [Link] in CustomerAAWeb.
Note: As customer package names start with [Link], there is no need to add new
packages here for logging, because [Link] is already added in Integral BASE
[Link] which customer will copy in customer package.

Page 22 of 45
Integral Code Extension Framework: DXC’s Integral
Integral Code Extension Framework Version 3.0

5.8 HANDLING [Link]

If customer wants to modify existing transaction, they will extend Pxxxx programs and
SxxxxScreenVars and will put child classes in Customer package. They will also need to
copy [Link] and [Link] into customer package
- [Link] in xxxxApp (i.e. CustomerAAApp)
- [Link] in xxxxWeb (i.e. CustomerAAWeb)

[Link] will be picked automatically from CustomerAAWeb, because overlay will

pick this one and ignore BASE JSP.
All [Link] files, be it new transaction or modification of existing one, customer should
keep in one folder in customer package and this folder should be defined at first place in
<SubFolders> tag in [Link].
For example, we have created customeraa folder in CustomerAAApp in
src/main/resources, as shown below:
[Link]
<SubFolders>customeraa/fsu/life/iaf/diary/common</SubFolders>

CustomerAAApp

5.9 HOW TO HANDLE DB OPERATIONS

For DB operations, we have DAO layer in Integral. We will introduce service layer in Code
Extension package, which will call DAO layer using spring auto-wiring.
As far as DB operations are concerned, we could have following situations:

5.9.1 Existing DB table

In case of existing DB table, there could be two situations:

Page 23 of 45
Integral Code Extension Framework: DXC’s Integral
Integral Code Extension Framework Version 3.0

[Link] Customer wants to use existing DB table structure

In this case if DAO already exists in BASE, we will add service in Code Extension
Service Package i.e. IntegralAFExtension, IntegralFSUExtension,
IntegralLife(Polisy/Group)Extension, depending upon whether DAO belongs to IAF, FSU
or LOB.
If DAO doesn’t exist, DAO will be first created in Integral BASE and then service in Code
Extension Service Package.
[Link] Customer wants to change DB table structure
If customer wants to change DB structure, for example, customer wants to add
new columns; customer will create DAO and service in customer package. If
DAO already exists in BASE they can extend them.

5.9.2 New DB table

As this new table is specific to customer only, customer will create DAO and service in
customer package. As far as data modeling is concerned, it should comply with Integral
BASE data model.

6 CREATING A NEW TRANSACTION IN CUSTOMER

PACKAGE – IMPLEMENTATION DETAILS
6.1 CSCINTEGRALEXTENSION
As a part of code extension package, we have implemented following.
- SmartTableService
- ClientService
- AppLocator – already explained in section 3.2.3

1. SmartTableService
It has two methods
- getSmartTablebyName()
This method reads a smart table based on smart table name. For example, T3642.
- getSmartTableItem()
This method read a specific item from a smart table.

2. ClientService
It has one method
- readClientData()
This method returns client details based on client number

Page 24 of 45
Integral Code Extension Framework: DXC’s Integral
Integral Code Extension Framework Version 3.0

6.2 CUSTOMERAAAPP
As a part of implementation, a transaction is created – Client Employment Details. In this
transaction user can
- Create Employment Details
- Modify Employment Details
- Inquire Employment Details

A new submenu screen and a transaction screen is created.

It involves following programs, screen vars etc. for two screens:

- [Link], [Link], [Link], [Link], [Link]
- [Link], [Link], [Link], [Link], [Link]

DAO and Services for customer specific table CLEMPPF are created:
- DAO: [Link], [Link], [Link]
- Service: [Link], [Link]

Customer specific *.path file and applicator are created:

- [Link], [Link]

Spring configuration files are created:

- [Link]
- [Link]
- [Link]

6.3 CUSTOMERAAWEB
It contains two JSP files for Client Employment Details transaction – [Link] and
[Link].

6.4 EXAMPLE – CLIENT EMPLOYMENT DETAILS

As already explained, in this transaction user can
- Create Employment Details
- Modify Employment Details
- Inquire Employment Details

Note: Smart table setups and user authorization is same as we currently do in Integral.

Client Employment Submenu Link

Page 25 of 45
Integral Code Extension Framework: DXC’s Integral
Integral Code Extension Framework Version 3.0

Screenshots for create/modify/inquire Client Employment Details are shown below.

6.4.1 Create Employment Details

Page 26 of 45
Integral Code Extension Framework: DXC’s Integral
Integral Code Extension Framework Version 3.0

Page 27 of 45
Integral Code Extension Framework: DXC’s Integral
Integral Code Extension Framework Version 3.0

6.4.2 Modify Employment Details

Page 28 of 45
Integral Code Extension Framework: DXC’s Integral
Integral Code Extension Framework Version 3.0

6.4.3 Inquire Employment Details

Page 29 of 45
Integral Code Extension Framework: DXC’s Integral
Integral Code Extension Framework Version 3.0

6.5 CODE CHANGES

Kindly refer following GitHub location for see the code details:

Code Extension Service Package

[Link]

Customer Package
[Link]

7 CREATING A NEW BATCH PROGRAM IN CUSTOMER

PACKAGE – IMPLEMENTATION DETAILS
We just created one batch program [Link] in CustomerAAApp to demonstrate that
customer could create new batch programs in customer specific package. This batch
simply prints clients list in one text file.
To get this program called by Integral, path is also added in [Link] file. A new
method is introduced in ClientpfDataDAO (part of CSCFsuApp) to fetch client list and
corresponding method is added in ClientService (part of CSCIntegralExtension). Bcl01 will
use this new method to fetch client list from Integral database.

Page 30 of 45
Integral Code Extension Framework: DXC’s Integral
Integral Code Extension Framework Version 3.0

7.1 CODE CHANGES

7.1.1 CSCFsuApp

[Link]

[Link]

Page 31 of 45
Integral Code Extension Framework: DXC’s Integral
Integral Code Extension Framework Version 3.0

7.1.2 IntegralFsuExtension
[Link]

[Link]

Page 32 of 45
Integral Code Extension Framework: DXC’s Integral
Integral Code Extension Framework Version 3.0

7.1.3 CustomerAAApp

New Programs
[Link]
This program implementation could be found at following GitHub location:
[Link]

Modified Files
[Link]

Batch Definition
Attached herewith is batch definition.

IJTI-183 - Batch
[Link]

Page 33 of 45
Integral Code Extension Framework: DXC’s Integral
Integral Code Extension Framework Version 3.0

8 MODIFY EXISTING SCREEN/TRANSACTION–

IMPLEMENTATION DETAILS
8.1 INTRODUCTION

For modifying existing screen, we will use Code Extension Points approach, which is part of
Code Extension framework approach.
Every screen in Integral has following files:
1. [Link]
2. [Link]
3. [Link]
4. [Link]
5. [Link]
6. [Link]
7. [Link]
8. [Link]

To modify existing screen following steps are required:

- Customer development team from DXC will need to modify Pxxxx,
SxxxxScreenVars, Sxxxxscreen, Sxxxxscreensfl and Sxxxxprotect in Integral Base
code.
- [Link] and [Link] files will be copied to customer package for customer
specific changes.
- Customer development team will create Pxxxxyyy (it will extend Pxxxx) and
SxxxxyyyScreenVars (it will extend SxxxxScreenVars) in customer package. Here
‘yyy’ indicates suffix that customer can use. For example – CLI team can use
Pxxxxcli, Zurich Japan team can use Pxxxxzjp etc.
- Creating DAO/Services for DB operations is same as described in previous
sections.

Note: For customer specific requirement to modifying existing screen/transaction, customer

will come to DXC and customer development team from DXC will study logic properly and
define code extension points (default methods in Integral BASE P programs. These
methods will be overridden in extended P program in customer specific package). TA should
define code extension points properly and write proper java doc comments, so that
developer can understand the intent.

8.2 STEPS
For our reference implementation, we have modified Sr203 screen (Bulk Receipts). We
will explain steps using Sr203 screen as reference.

Page 34 of 45
Integral Code Extension Framework: DXC’s Integral
Integral Code Extension Framework Version 3.0

8.2.1 Modify [Link]

In [Link], variable definition pfInds needs to be removed/commented and
following three methods need to be modified:
- write()
- clearClassString(VarModel pv)
- clear(VarModel pv)

Note: Change in clearClassString() and clear() is required, if these methods contain

code to clear fields. Otherwise not required.
Sr203screen doesn’t have code to clear fields, so I am showing sample snapshot for
other Screen (S2200screen)

Old Code

Page 35 of 45
Integral Code Extension Framework: DXC’s Integral
Integral Code Extension Framework Version 3.0

New Code

Page 36 of 45
Integral Code Extension Framework: DXC’s Integral
Integral Code Extension Framework Version 3.0

8.2.2 Modify [Link]

Changes in Sxxxxprotect are same as changes in Sxxxxscreen.

8.2.3 Modify [Link]

Like Sxxxxscreen, Sxxxxscreenctl requires removing/commenting pfInds variable and
changing write() method.
Apart from that following methods require modification if Sxxxxscreenctl contains code to
clear fields:
- clearClassString(VarModel pv)
- clear(VarModel pv)

Old Code

Page 37 of 45
Integral Code Extension Framework: DXC’s Integral
Integral Code Extension Framework Version 3.0

New Code

Page 38 of 45
Integral Code Extension Framework: DXC’s Integral
Integral Code Extension Framework Version 3.0

8.2.4 Modify [Link]

In all Sxxxxscreensfl, you need to change code in following way:
1. Comment/remove pfInds and affectedInds variables. These we will move to
SxxxxScreenVars.
2. Comment/remove getSubfileData(), setSubfileData() and clearClassString()
methods completely.
3. Modify methods: write(), update(),readNextChangedRecord(), chain(),
set1stScreenRow(), setNextScreenRow() and clearFormatting().

First two points are straightforward; we will show code snapshots for third point.
[Link] write()
Old Code

Page 39 of 45
Integral Code Extension Framework: DXC’s Integral
Integral Code Extension Framework Version 3.0

New Code

[Link] update()
Old Code

New Code

[Link] readNextChangedRecord()
Old Code

Page 40 of 45
Integral Code Extension Framework: DXC’s Integral
Integral Code Extension Framework Version 3.0

New Code

[Link] chain()
Old Code

New Code

[Link] set1stScreenRow()
Old Code

New Code

Page 41 of 45
Integral Code Extension Framework: DXC’s Integral
Integral Code Extension Framework Version 3.0

[Link] setNextScreenRow()
Old Code

New Code

[Link] clearFormatting()
Old Code

New Code

8.2.5 Modify [Link]

Note: Suppose you are modifying existing screen and you want to use indicators.
Integral at present supports 200 indicators. First 150 indicators are reserved for
BASE and customer specific fields should use indicators from 150-200. This is
required, because otherwise if something develops in BASE in future and indicators
collide, screen might behave abruptly
Page 42 of 45
Integral Code Extension Framework: DXC’s Integral
Integral Code Extension Framework Version 3.0

In SxxxxScreenVars, couple of new methods need to be added to make it

extendible. Apart from that, pfInds and affectedInds from Sxxxxscreensfl are now
put as screenSflPfInds and screenSflAffectedPfInds in SxxxxScreenVars.
Changes is SxxxxScreenVars are self-explanatory.
Old Code

[Link]

New Code

[Link]

8.2.6 Modify [Link]

To make Pxxxx extendible, it is required to change the way sv variable is being
initialized. This requires to create a new method getPScreenVars().
Old Code

New Code

Remarks:
1. Sometimes, it could be required to get some variables from base Pxxxx in customer
extended programs. For those, we can create getters and setters in Pxxxx programs.
2. Code change showed in snapshot above is always required. Apart from this, when
customer requirement will come to modify existing transaction/screen, TA should
Page 43 of 45
Integral Code Extension Framework: DXC’s Integral
Integral Code Extension Framework Version 3.0

properly define code extension points in Pxxxx programs, which will be overridden in
extended Pxxxxyyy programs in customer package to inject customer specific
implementation.

8.2.7 Write [Link] (in Customer package)

This Pxxxxyyy will extend Pxxxx. This will override getPScreenVars() method. For our
reference implementation, we have created [Link] (in CustomerAAApp)
extending [Link].
Note: While writing extended program, ensure to add following annotations:

Where,
@Component: This name should be Integral BASE Pxxxx program
@Scope: it should be prototype
@Lazy: it should be lazy initialization

8.2.8 Registering [Link] as Spring bean

We will use component scan to register extended Pxxxxyyy program. For this, you
should add context:component-scan in customer specific spring configuration file.

In reference implementation, we have added following code in [Link].

8.2.9 Write [Link] (in Customer package)

SxxxxyyyScreenVars will contain customer specific fields and extend SxxxxScreenVars.
For our reference implementation, we have created Sr203xxxScreenVars extending
Sr203ScreenVars.

8.2.10 Copy [Link] and [Link] in Customer package

Customer will need to copy [Link] and [Link] into customer package and
modify them as per customer requirement.

Page 44 of 45
Integral Code Extension Framework: DXC’s Integral
Integral Code Extension Framework Version 3.0

8.2.11 Write subroutines in Customer Package

Customers are free to create new subroutine in customer package, just like we do in
Integral BASE.
If customer wants to change logic in existing subroutines, they will extend BASE
subroutine into customer package. For example, if subroutine name is Dbtmryoluw,
they will write subroutine with name Dbtmryoluwyyy extending Dbtmryoluw. Here yyy
is suffix as explained in section 8.1. Customer can define new Subroutine as spring
bean, as explained in case of P programs.
Sample Snapshot

8.3 CODE DETAILS

All code details described in section 8.2 can be found at following GitHub locations:
Customer Specific Implementation
[Link]

Integral Base Code

[Link]

Page 45 of 45
Integral Code Extension Framework: DXC’s Integral