Introduction

This chapter describes the necessary object or service module for creating an online program using ProFrame.

1. Overview

The online program is executed by each unit system in the Multi-Channel Architecture (MCA) system or Enterprise Application Integration (EAI) system of customer, teller, or ATM, and has an independent transaction. The online program leaves the image log and the business log for all transactions.

  • MCA(Multi-Channel Architecture)

    It is a structure that makes a whole system by using an interface that integrates various channels.

  • EAI(Enterprise Application Integration)

    It is an environment that can integrate, manage, and use necessary information by organically linking all interrelated applications within the enterprise.

Consider the following when selecting a target to create an online program.

  • Functionality and singularity

    Select the target based on function and it should have singularity. Singularity means the smallest unit with a unique function.

  • Independent transaction

    Create when it is recognized as an independent transaction. In other words, it is created when it is necessary to leave a separate work log.

  • Transaction Separation

    Create when it is necessary to separate transactions.

2. Service Module

In ProFrame, online programs are created in the form of service modules. A service module is a program that is called when connecting to other modules.

The characteristics of service module are as follows:

  • It is the same as the service of TP-Monitor.

  • A business unit for online transaction processing.

  • It has a post-processing module. CommBuff can be read and written in service module and post-processing of task.

  • One service module for each transaction code.

  • One input/output structure can be specified.

  • It is a program called directly from a channel or unit system.

3. Singularity of Service Module

Singularity refers to the smallest unit of unique functions. As the service module has more singularities, the reusability of the module increases. Developers who use a module with added complex functions need to understand the functions of the module accurately, because the complexity increases reusability of the module and the error rate of the program. So, the deposit service must have only a deposit function, and the withdrawal service must have only a withdrawal function.

For example, a service module that has both deposit and withdrawal functions must be created as a separate new service that links deposit and withdrawal services.

4. Call Relationship between Service Module and Other Modules

The service module is the starting node, and all transactions start and end through the service module. On the other hand, since the Business module, Virtual module, DBIO module, etc. are leaf nodes, it is not recommended to call the service module from these modules due to the side effect of reducing the reusability of the module.

For information on each module and function that is the design unit of EMB module in EMB Designer, refer to ProFrame EMB Developer Guide.

The following describes the call relationship between the service module and other modules.

  • Business Module

    Contains business logic. It is possible to call all modules, but it is not possible to call service module directly in business modules.

  • Inner Module (hereinafter IM), Loop Module (hereinafter LM)

    Connects nodes between nodes as an edge. It calls any module.

  • Virtual Module (hereinafter VM), Virtual Function (hereinafter VF), DBIO Module

    Performs the role of an end node. It cannot call other modules.