Multi-project development

A banking application possibly has multiple channels, such as teller banking, internet private banking, corporate banking, etc. These applications may be required to share some common business logic or resources such as operations and flows, NLS files or image files. At development time, the applications are organized as multiple projects in the development environment.

UNICOM^® Digital Transformation Toolkit (UDTT™) supports reference of resources in a project from other projects. For example, developers can choose NLS definition from one project for a widget of another project. The multi-project support increases the maintainability of the application code and flexibility of project management as well as decreasing the code redundancy.

Also it increases the runtime flexibility by hot deployment capabilities. For example, when part of the shared sub-flow business logic is changed or the web resource is changed, you need to re-deploy only the shared EAR, the base business-specific application EAR does not need to be restarted.

To develop application based on multiple projects, there should be a senior technical developer that design the multiple projects structure and create the project at first.

For more information, see Multi-project structure.

Configuring the development environment to support multi-project structure on Application Server Liberty profile

Multi-project structure is supported on Liberty profile V22 in the UNICOM^® Digital Transformation Toolkit version 10.4 and later, Liberty profile V8.5.5 in the UNICOM^® Digital Transformation Toolkit versions 9 and 10, and the UNICOM® Multichannel Bank Transformation Toolkit V8.2.x. You need to configure your development environment before you develop applications with multi-project structure on Liberty profile.

For more information, see Configuring the development environment to support multi-project structure on Application Server Liberty profile.

Once the multi-project structure has been created by the technical developers, the functional developers will be able to use the shared components in any transaction definition.

For more information, see Access to shared components.

Multi-project environment configuration should be as much transparent as possible for the functional developer, which should have access to the appropriate UDTT components and resources without knowing their origin.