서비스 연동

본 장에서는 서비스 연동의 기본 개념과 서비스 연동별 구현 방법에 대해 설명한다.

1. 개요

서비스 연동[은 서로 다른 서비스들 간에 상호 호출하는 방식으로 이루어지는 서비스의 조합을 뜻한다. 이러한 서비스 연동은 분류 기준에 따라 여러 종류로 나눌 수 있다.

다음은 분류 기준에 따른 서비스 연동의 종류이다.

분류 기준 서비스 연동 종류

처리 위치

  • 선수 연동

  • 즉시 연동

  • 후속 연동

처리 개수

  • 1:1 연동

  • 멀티 연동

  • 일괄 연동

대상 위치

  • 내부 연동

  • Async 외부 연동

  • 타 시스템 연동

위와 같은 서비스 연동 중에 ProFrame는 총 3개의 서비스 연동만을 지원한다.

  • 즉시 연동

  • 1:1 연동

  • 내부 연동

    내부 연동은 코어 내부에서 서비스 모듈 상호 간의 호출을 통해 단품성 거래들의 조합으로 이루어지는 트랜잭션을 의미한다. 이렇게 내부 연동을 수행하는 서비스는 CommBuff를 사용하여 통신하며 코어 온라인 내부 연동과 코어 배치 연동으로 구분하여 실행할 수 있다.

    다음은 내부 연동에 대한 설명이다.

    • 내부 연동은 CommBuff를 사용하여 연동한다.

    • 서비스 간 연동을 작성하는 방법은 이미 생성된 서비스 모듈을 드래그 앤드 드롭하여 연결한다.

본 안내서는 ProFrame에서 지원하는 서비스 연동 중에 내부 연동을 기준으로 설명한다.

다음은 각 모듈의 연동 유형에 따라 지원되는 방식이다.

연동 유형 지원 방식 및 설명

서비스 모듈→비즈니스 모듈

DlCall 방식(DlCall 방식으로 비즈니스 모듈을 호출)

서비스 모듈↔서비스 모듈

DlCall 및 TpCall 방식

서비스 모듈→배치 모듈

DlCall 및 TpCall 방식

배치 모듈→서비스 모듈

ProFrame에서 제공하는 모듈을 통해서만 가능하다.

2. 서비스 연동의 종류별 지원 유형

ProFrame는 서비스 모듈을 호출하는 방법에 따라 DlCall 방식과 TpCall 방식으로 나눌 수 있다.

다음은 TpCall 및 DlCall 방식에 대한 장단점이다.

TpCall DlCall

장점

  • 변경된 로직의 TP-Monitor만을 재기동하는 방법으로 신규 업무 로직으로 교체가 가능하다.

  • 별도의 Shared Memory가 필요하지 않고 M/W API를 통한 자유로운 통신이 가능하다.

  • 개발자의 판단에 따라 1-Tx, N-Tx의 자유로운 트랜잭션 처리가 가능하다.

  • IPC 메커니즘이 필요 없으며 함수호출과 유사한 수준의 낮은 부하로 처리될 수 있다.

  • Dlupdate 기능으로 변경된 업무로직만 동적 교체가 가능하다.

  • Shared Library 정책이 포함되어 메모리 자원을 항상 효율적으로 관리할 수 있다.

단점

IPC 메커니즘이 필요하므로 시스템의 부하가 있다.

  • 별도의 Shared Memory 사용으로 메모리

  • 자원 사용량이 증가하고 관리 포인트가 증가한다.

  • 1-Tx 방식만 처리할 수 있다.

적용기준

별도의 트랜잭션으로 분리되어야 하는 거래

(예) 비밀번호 오류증가 서비스

주연동에서 피연동 서비스 처리를 일방적으로 지시하고 주연동은 계속 처리하는 거래

(예) 입금 거래 내역 SMS 통보

타 시스템 연동 거래

(예) 대외거래, 대내거래

코어 내부의 일반 연동거래

(예)

  • 지급 - 입금 연동 거래

  • 지급 - 당좌 입금 거래

IPC(InterProcess Communication)는 하나의 운영체제에서 동시에 수행될 개별 프로세스 간의 통신을 뜻한다.

DlCall과 TpCall은 각각 지원 가능한 트랜잭션 유형이 정해져 있다. 연동 트랜잭션을 작성할 때 2가지 방식의 지원 가능한 트랜잭션 유형의 장단점을 고려하여 어떤 방식을 이용할 것인지 결정해야 한다.

다음은 DlCall과 TpCall 방식에 대한 설명이다.

  • DlCall

    DlCall은 피연동 모듈을 직접 호출하여 연동하는 방식으로 Async 모드에 대한 지원은 하지 않으며 Sync 모드의 1-Tx에 대해서만 DlCall을 사용할 수 있다.

    Async는 주연동에서 피연동 서비스를 요청한 후 응답을 대기하지 않고 주연동의 프로세스를 처리하는 모드이고, Async Reply는 주연동에서 피연동 서비스를 요청한 후 응답을 받을 설정하며, 응답 요청을 하면 응답을 받을 때까지 대기한다.

    Sync Async(Async No Reply 방식)

    1-Tx

    가능

    불가능

    N-Tx

    불가능

    불가능

    1-Tx는 주연동과 피연동 서비스가 하나의 트랜잭션으로 처리되는 것이고 N-Tx는 주연동과 피연동 서비스가 트랜잭션이 분리되어 처리되는 것을 의미한다.

  • TpCall

    TpCall 방식을 사용하는 경우 Sync 모드를 사용할 때 1-Tx 및 N-Tx 방식을 사용할 수 있다. 그러나 1-Tx 방식의 경우 모듈을 직접 호출하는 연동 방식이 성능상 빠른 장점을 보이고 있기 때문에 Sync 모드의 1-Tx 방식의 경우에는 DlCall을 사용하여 연동할 것을 권장한다.

    추가적으로 Async 모드를 사용할 때는 N-Tx 방식만 사용할 수 있다.

    Sync Async(Async No Reply 방식)

    1-Tx

    가능

    (성능 문제로 인해 DlCall를 사용할 것을 권장한다.)

    불가능

    N-Tx

    가능

    가능

    Sync는 주연동에서 피연동 서비스를 요청한 후 응답이 올 때까지 대기하는 모드이고, Async No Reply는 피연동의 응답을 기다리지 않는다.

3. 서비스 연동의 구현

서비스 연동을 구현하는 방법은 서비스 모듈이 포함된 EMB Designer에서 다른 서비스 모듈을 마우스로 드래그 앤드 드롭하여 추가한다. 이때 추가한 서비스 모듈의 속성 중 Call Property 속성을 수정하여 서비스 연동을 구현한다.

3.1. Call Property

서비스 연동에 대한 속성은 스튜디오의 특성 뷰에서 설정할 수 있다. 여기서 추가된 서비스 모듈을 선택하면 특성 뷰에서 아래 그림과 같은 Call Property 속성이 나타난다.

figure3 1
Call Property 속성 예

다음은 Call Property 속성에 대한 설명이다.

속성 설명

Callee name

연동 모듈명으로 서비스 모듈을 드래그 앤드 드롭할 때 자동으로 설정 된다.

Call Kind

연동 종류를 설정한다.

서비스 연동을 DlCall 방식으로 할 것인지, TpCall 방식으로 할 것인지 설정한다. 예를 들어 DlCall 방식인 경우 1-Tx, Sync 처리만 가능하다.

  • L : Local Call (모듈 호출, DlCall 방식) (기본값)

  • R : Remote Call(TP-Monitor 서비스 기반 호출, TpCall 방식)

'Call Kind'는 연동 모듈에 대하여 DlCall을 수행할지 TP-Monitor 서비스 호출 기반의 TpCall을 수행할지를 결정하는 속성이다. 일반적으로 내부 연동을 위해서는 모듈 호출을 수행하기 위해 DlCall로 설정하지만, 그 외 특수한 경우에는 TpCall로 설정하기도 한다.

  • Local Call일 경우 1-Tx, Sync 처리만 가능하다. 따라서 1-Tx, Sync 모드로 연동하는 경우에는 ‘L’을 선택해야 한다. 대부분의 내부 연동이 이와 같은 설정으로 연동한다.

  • Local Call일 경우 IPC가 발생하지 않아 성능이 좋다. 따라서 1-tx, Sync 모드로 연동하는 경우 반드시 Local Call을 선택해야 한다.

  • Async 모드이거나 N-Tx로 처리하는 경우에는 반드시 ‘R’을 선택해야 한다. Local Call은 모듈기반의 호출이기 때문에 Async 처리할 수 없다.

  • Remote Call일 경우 주연동 및 피연동 서비스 중 하나만 연동할 수 있으며, Non-XA 서버라면 1-Tx 방식으로 연동할 수 없다.

  • Local Call일 경우 피연동 사용자 처리 로그가 주연동 서비스 로그에 쌓인다.

  • Remote Call일 경우는 주연동 및 피연동 서비스 모듈이 속한 TPMonitor 서버에 각각의 로그가 쌓인다.

Shared pre-processing

피연동으로 시스템 선처리 수행 여부를 설정한다.

  • 0: Not perform(수행하지 않음)(기본값)

  • 1: Perform(수행)

Shared post-processing

피연동으로 시스템 후처리 수행 여부를 설정한다.

  • 0: Not perform(수행하지 않음)(기본값)

  • 1: Perform(수행)

Sync

피연동을 Sync 모드로 호출하는 경우 피연동이 반환될 때까지 주연동 서비스가 대기한다.

피연동을 Async 모드로 호출하는 경우 주연동에서 피연동을 호출한 즉시 주연동의 로직이 계속 수행된다.

  • S: Sync(기본값)

  • A: Async and No Reply

  • a: Async and GetReply

Team shared pre-processing

피연동으로 업무 선처리 수행 여부를 설정한다.

  • 0: Not perform(기본값)

  • 1: Perform

Team shared post-processing

피연동으로 업무 후처리 수행 여부를 설정한다.

  • 0: Not perform(기본값)

  • 1: Perform

Transaction

트랜잭션 처리구분을 설정한다.

  • 1: 1-Tx(기본값)

주연동 서비스와 피연동 서비스를 하나의 트랜잭션으로 처리하는 경우 1-Tx(주연동에 의해 피연동의 커밋/롤백이 결정) 방식으로 설정한다.

  • N: Tx

주연동 서비스와 피연동 서비스의 트랜잭션을 분리하는 경우 N-Tx(주연동 및 피연동의 커밋/롤백이 각각 따로 처리) 방식으로 설정한다.

3.2. DlCall 방식의 연동방법

내부 연동의 일반적인 경우는 Call Property 설정을 내부 연동 Call Property의 기본 설정 값을 사용한다. DlCall 방식을 사용할 때 연동 설정은 Sync/1-Tx 처리만이 가능하다.

DlCall로 피연동 서비스 모듈을 호출할 경우

DlCall로 피연동 서비스 모듈을 호출하는 경우에는 주연동을 수행하기 위한 모듈과 피연동 수행을 위한 모듈에 대한 EMB 모듈 작성이 완료되어야 한다.

figure3 2
EMB Designer – 피연동 서비스 DlCall 호출 예

다음은 피연동 서비스 모듈에 대해 DlCall을 호출하는 소스 예제이다.

static long InnerModule2(ManualServiceModuleContext *context)
{
    long rc = RC_NRM;

    // User Variables Declaration

    {
        /**************************************
         * KIND     : Service Module Call
         * NODE ID  : 5
         * NAME     :
         * DESCRIPTION :
          *************************************/
①      PfmLinkHeader linkHeader = { "CustomerInfoManagerment",
              "CustomerInfoManagerment", "PFM4", 'L', 0, 0, 0, 0, '1', 'S'};
        STR1_IN temporaryInput;
        STR1_OUT temporaryOutput;

        bzero(&temporaryInput, sizeof(STR1_IN));
        bzero(&temporaryOutput, sizeof(STR1_OUT));
        //DO_NOT_MODIFY_THIS_LINE-----------START_OF_CODE:BEFORE_CODE NODEID5------------------//
②      context->inCtxCustomerInfoManagerment.empno = INPUT->empno;//empno = empno
        //DO_NOT_MODIFY_THIS_LINE-----------END_OF_CODE:BEFORE_CODE NODEID5------------------//

        /**************************************
         *   KIND        : Service Module Callee Info
         *   NAME        : true
         *   INPUT       : STR1_IN
         *   OUTPUT      : STR1_OUT
         *************************************/
③      PFM_TRY(pfmServiceModuleCall(&temporaryInput, &temporaryOutput, &linkHeader, sizeof(STR1_IN), sizeof(STR1_OUT)));
        //DO_NOT_MODIFY_THIS_LINE-----------START_OF_CODE:SERVICE_MODULE_EXCEPTION NODEID5------------------//

        //DO_NOT_MODIFY_THIS_LINE-----------END_OF_CODE:SERVICE_MODULE_EXCEPTION NODEID5------------------//

        //DO_NOT_MODIFY_THIS_LINE-----------START_OF_CODE:AFTER_CODE NODEID5------------------//
④      OUTPUT->empno = context->outCtxCustomerInfoManagerment.empno;//empno = empno
        //DO_NOT_MODIFY_THIS_LINE-----------END_OF_CODE:AFTER_CODE NODEID5------------------//
    }
    return RC_NRM;

PFM_CATCH:
    return rc;
}

다음은 위 소스 중 각 번호에 대한 설명이다.

① Call Property 설정에 따른 Link Header 옵션이다.

Call Property 옵션 값

Callee name

"CustomerInfoManagerment"

Transaction Code

"CustomerInfoManagerment"

Inst Number

"PFM4"

Call Kind

'L'

Shared Pre-Processing

0

Shared Post-Processing

0

Team Shared Pre-Processing

0

Team Shared Post-Processing

0

Transaction Type

'1'

Sync Type

'S'

② 입력 구조체를 매핑한다.

③ 서비스 모듈을 호출한다.

④ 출력 구조체를 매핑한다.

3.3. TpCall 방식의 연동방법

본 절에서는 TpCall로 피연동 서비스 모듈을 호출할 경우에 대해서 설명한다.

대부분의 서비스 연동은 Call Property의 설정 없이 피연동 모듈을 주연동 모듈의 EMB 모듈에 드래그 앤드 드롭함으로써 연동이 가능하다. 하지만 DlCall을 사용하는 서비스 연동은 트랜잭션을 분리하여 처리할 수 없기 때문에 내부 연동 중 일부는 TpCall 방식으로 피연동 모듈을 호출하여 사용한다.

TpCall 방식을 사용하게 되면 주연동과 피연동 모듈 간의 비동기 처리가 가능하며, 트랜잭션을 나누어 처리하는 것도 가능하다. 이것은 Call Property의 'Call Kind', 'Sync Type', 'Transaction Type' 항목의 값을 설정함으로써 가능하다.

TpCall 방식은 트랜잭션이 분리되어야 하는 연동 서비스를 호출할 때 사용한다. 주연동 처리를 위한 모듈과 피연동 처리를 위한 모듈이 EMB Designer에 작성되어 있어야 한다. 또한 대부분의 내부 연동처리 과정이 일반적인 경우의 내부 연동작성과 동일하나 Call Property를 설정하는 부분에서만 차이점을 보인다.

EMB Designer 상에서 내부 연동타입 설정을 위한 모듈을 설정한 후 ProFrame 스튜디오에서 [특성] 뷰를 확인하면 내부 연동타입 설정이 가능한 Call Property가 표시된다.

다음은 피연동이 서비스 모듈인 경우 TpCall 방식을 사용하여 Sync 및 Async 모드별로 1-Tx 또는 N-Tx 처리하는 방법에 대한 설명한다.

  • Sync

    구분 설명

    1-Tx 처리 방식

    TpCall을 사용하여 Sync 모드 및 1-Tx 방식으로 처리하는 경우 모듈을 직접 호출하는 DlCall에 비해 TP-Monitor 서비스 기반의 호출을 수행하는 TpCall의 성능이 저하되는 단점이 있어 Sync/1-Tx 방식으로 처리할 때는 DlCall을 사용할 것을 권장한다.

    N-Tx 처리 방식

    트랜잭션을 분리하여 처리하며 동기화 처리방식으로 연동 처리를 수행한다. 자세한 내용은 Sync : N-Tx 처리 방식을 참고한다.

  • Async

    구분 설명

    No Reply/1-Tx 처리

    이 처리 방식은 사용할 수 없는 구조이다.

    No Reply/N-Tx 처리

    이 방식은 비동기 처리를 수행하며 피연동 모듈의 응답을 기다리지 않고 주연동 및 피연동 모듈의 트랜잭션을 분리하여 수행하는 방식이다. 자세한 내용은 Async : No Reply/N-Tx 처리를 참고한다.
Sync : N-Tx 처리 방식

트랜잭션을 분리하여 처리하며 동기화 처리방식으로 연동 처리를 수행한다. 주연동 모듈과 피연동 모듈은 각기 다른 트랜잭션으로 처리되며 주연동 및 피연동 처리에 관한 로그는 주연동과 피연동 모듈이 속한 TP-Monitor 서버에 남게 된다.

다음은 TpCall/Sync/N-Tx 처리에 대한 설명이다.

figure3 3
TpCall/Sync/N –Tx 처리 – Call Property 설정 예

다음은 TpCall/Sync/N-Tx 처리를 위한 서비스 모듈에 대한 소스 예제이다.

static long InnerModule2(ManualServiceModuleContext *context)
{
    long rc = RC_NRM;

    // User Variables Declaration

    {
        /**************************************
         * KIND     : Service Module Call
         * NODE ID  : 5
         * NAME     :
         * DESCRIPTION :
         *************************************/
①      PfmLinkHeader linkHeader = { "CustomerInfoManagerment",
                 "CustomerInfoManagerment", "PFM4", 'R', 0, 0, 0, 0, 'N', 'S'};
        STR1_IN temporaryInput;
        STR1_OUT temporaryOutput;

        bzero(&temporaryInput, sizeof(STR1_IN));
        bzero(&temporaryOutput, sizeof(STR1_OUT));
        //DO_NOT_MODIFY_THIS_LINE-----------START_OF_CODE:BEFORE_CODE NODEID5------------------//
②      context->inCtxCustomerInfoManagerment.empno = INPUT->empno;//empno = empno
        //DO_NOT_MODIFY_THIS_LINE-----------END_OF_CODE:BEFORE_CODE NODEID5------------------//

        /**************************************
         *   KIND        : Service Module Callee Info
         *   NAME        : true
         *   INPUT       : STR1_IN
         *   OUTPUT      : STR1_OUT
         *************************************/
③      PFM_TRY(pfmServiceModuleCall(&temporaryInput, &temporaryOutput, &linkHeader, sizeof(STR1_IN), sizeof(STR1_OUT)));
        //DO_NOT_MODIFY_THIS_LINE-----------START_OF_CODE:SERVICE_MODULE_EXCEPTION NODEID5------------------//

        //DO_NOT_MODIFY_THIS_LINE-----------END_OF_CODE:SERVICE_MODULE_EXCEPTION NODEID5------------------//

        //DO_NOT_MODIFY_THIS_LINE-----------START_OF_CODE:AFTER_CODE NODEID5------------------//
④      OUTPUT->empno = context->outCtxCustomerInfoManagerment.empno;//empno = empno
        //DO_NOT_MODIFY_THIS_LINE-----------END_OF_CODE:AFTER_CODE NODEID5------------------//
    }
    return RC_NRM;

PFM_CATCH:
    return rc;
}

다음은 위 소스 중 각 번호에 대한 설명이다.

① Call Property 설정에 따른 Link Header 옵션이다.

Call Property 옵션 값

Callee name

"CustomerInfoManagerment"

Transaction Code

"CustomerInfoManagerment"

Inst Number

"PFM4"

Call Kind

'R'

Shared Pre-Processing

0

Shared Post-Processing

0

Team Shared Pre-Processing

0

Team Shared Post-Processing

0

Transaction Type

'N'

Sync Type

'S'

② 입력 구조체를 매핑한다.

③ 서비스 모듈을 호출한다.

④ 출력 구조체를 매핑한다.

Async : No Reply/N-Tx 처리

이 방식은 비동기 처리를 수행하며 피연동 모듈의 응답을 기다리지 않고 주연동 및 피연동 모듈의 트랜잭션을 분리하여 수행하는 방식이다.

다음은 TpCall/Async-No Reply/N-Tx 처리에 대한 설명이다.

figure3 4
TpCall/Async – No Reply/N-Tx 처리 – Call Property 설정 예

다음은 TpCall/Async-No Reply/N-Tx 처리를 위한 서비스 모듈에 대한 소스 예제이다.

static long InnerModule2(ManualServiceModuleContext *context)
{
    long rc = RC_NRM;

    // User Variables Declaration

    {
        /**************************************
         * KIND     : Service Module Call
         * NODE ID  : 5
         * NAME     :
         * DESCRIPTION :
         *************************************/
①      PfmLinkHeader linkHeader = { "CustomerInfoManagerment",
                  "CustomerInfoManagerment", "PFM4", 'R', 0, 0, 0, 0, 'N', 'A'};
        STR1_IN temporaryInput;
        STR1_OUT temporaryOutput;

        bzero(&temporaryInput, sizeof(STR1_IN));
        bzero(&temporaryOutput, sizeof(STR1_OUT));
        //DO_NOT_MODIFY_THIS_LINE-----------START_OF_CODE:BEFORE_CODE NODEID5------------------//
②      context->inCtxCustomerInfoManagerment.empno = INPUT->empno;//empno = empno
        //DO_NOT_MODIFY_THIS_LINE-----------END_OF_CODE:BEFORE_CODE NODEID5------------------//

        /**************************************
         *   KIND        : Service Module Callee Info
         *   NAME        : true
         *   INPUT       : STR1_IN
         *   OUTPUT      : STR1_OUT
         *************************************/
③      PFM_TRY(pfmServiceModuleCall(&temporaryInput, &temporaryOutput, &linkHeader, sizeof(STR1_IN), sizeof(STR1_OUT)));
        //DO_NOT_MODIFY_THIS_LINE-----------START_OF_CODE:SERVICE_MODULE_EXCEPTION NODEID5------------------//

        //DO_NOT_MODIFY_THIS_LINE-----------END_OF_CODE:SERVICE_MODULE_EXCEPTION NODEID5------------------//

        //DO_NOT_MODIFY_THIS_LINE-----------START_OF_CODE:AFTER_CODE NODEID5------------------//
④      OUTPUT->empno = context->outCtxCustomerInfoManagerment.empno;//empno = empno
        //DO_NOT_MODIFY_THIS_LINE-----------END_OF_CODE:AFTER_CODE NODEID5------------------//

    }
    return RC_NRM;

PFM_CATCH:
    return rc;
}

다음은 위 소스 중 각 번호에 대한 설명이다.

① Call Property 설정에 따른 Link Header 옵션이다.

Call Property 옵션 값

Callee name

"CustomerInfoManagerment"

Transaction Code

"CustomerInfoManagerment"

Inst Number

"PFM4"

Call Kind

'R'

Shared Pre-Processing

0

Shared Post-Processing

0

Team Shared Pre-Processing

0

Team Shared Post-Processing

0

Transaction Type

'N'

Sync Type

'A'

② 입력 구조체를 매핑한다.

③ 서비스 모듈을 호출한다.

④ 출력 구조체를 매핑한다.

3.4. 내부 연동 CommBuff 데이터 전달

코어 내부의 서비스 또는 서비스 모듈 간의 내부 연동을 수행할 때 주연동 및 피연동 모듈 간의 데이터 전달은 CommBuff를 통해 일어난다.

CommBuff는 크게 프레임워크 영역과 업무 영역으로 나뉜다.

  • 프레임워크 영역

    서비스 간 전달이 가능한 영역으로 내부 연동하는 경우 프레임워크 영역에 의해 코어 내부의 서비스로 전달된다.

  • 업무 영역

    업무 내 공유가 가능한 영역이다. 단, 다른 온라인 업무에는 전달되지 않는다.

다음은 CommBuff Slot의 구성에 대한 설명이다.

figure3 5
CommBuff Slot 구성

  • 프레임워크 System 영역

    프레임워크 시스템 내부적으로 사용하는 공간으로 프로젝트와 상관없이 동일한 항목을 가지고 있다.

  • 프레임워크 Project System 영역

    프레임워크 시스템 내부적으로 사용하며 프로젝트 요건에 따라 수정되어 사용된다.

  • Project Business 영역

    프로젝트 업무 요건에 따라 업무팀에 할당되어 사용된다.

CommBuff Slot 구성 CommBuff Slot 구성에서 0~123번까지는 내부 연동 간에 CommBuff를 통해 데이터가 전달되는 영역을 프레임워크에서 데이터를 전달하며 업무 내 공유 영역에 대해서는 해당 업무 사이의 CommBuff Slot의 내용을 조립하여 정의된 매크로를 사용하여 데이터 전달을 수행한다.

내부 연동을 수행할 때 주연동 모듈과 피연동 모듈 간의 CommBuff를 사용한 데이터 전달은 아래 그림과 같은 순서로 이루어진다.

figure3 6
내부 연동의 CommBuff 사용 흐름도

다음은 위 그림에 대한 설명이다.

① DUPLICATE

주연동의 CommBuff를 복제한다.

② TPCALL

피연동 서비스를 호출하면서 복제된 CommBuff 데이터를 전달한다.

③ SET_ITEM

피연동 서비스에서 전달 받은 CommBuff 데이터를 변경한다.

④ TPRETURN

주연동 서비스에 변경된 CommBuff를 결과 값으로 반환한다.

⑤ RECOVER

피연동 서비스에 의해 변경된 CommBuff 데이터를 복제 이전의 CommBuff로 복원한다.

⑥ FREE

①에서 복제된 CommBuff를 해제한다.

⑦ TPRETURN

최종 결과 값을 클라이언트 컴퓨터로 전송한다.

CommBuff를 해제하지 않으면 메모리 부족 현상이 발생하므로 주연동 모듈은 반드시 CommBuff 해제 작업을 수행해야 한다.

4. 서비스 연동 구현할 때 주의사항

서비스 모듈은 다른 서비스 모듈을 포함한 모든 모듈을 호출할 수 있다. 또한 DBIO 등과 같은 ProFrame에서 생성할 수 있는 리소스 모듈도 호출할 수 있다. 단, 자기 자신의 모듈을 재호출할 수 없으며 이것은 무한 루프에 빠질 수 있음으로 주의해야 한다.

figure3 7
자기 자신을 호출하는 경우 에러 알림 창

4.1. CommBuff 사용

서비스 모듈은 비즈니스 모듈과 같은 다른 모듈과 달리 CommBuff를 사용할 수 있다. 단, 선처리 모듈과 후처리 모듈은 CommBuff를 사용할 수 있다.

  • 서비스 모듈의 CommBuff 정보

    figure3 8

  • 선처리 모듈의 CommBuff 정보(미정의)

    figure3 9

  • 그 외 모듈 - CommBuff 정보 없음

    figure3 10

4.2. CommBuff 항목 사용 제한

프레임워크 내부적으로 사용하는 CommBuff 항목을 변경하는 경우 프레임워크의 안정성과 정합성에 문제가 발생하기 때문에 변경하면 안 된다.

아래 표에서 언급된 CommBuff의 주요 항목에 대해서는 될 수 있으면 개발자가 직접 변경을 해서는 안 되며 만약 변경이 필요할 경우에는 ProFrame에서 제공하는 API를 사용하여 변경한다.

CommBuff 항목 용도 변경여부

PFM_HDR_EXT

ProFrame 표준 전문헤더 내용

변경 가능

PFM_LOGHEAD

업무 로그 헤더부

변경 가능

PFM_VAR_SHARE

프레임워크 내부 자료

변경 불가

PFM_SVCPARAM

서비스 파라미터

변경 불가

4.3. EMB 모듈 디자인

온라인 프로그램은 초기처리, 입력 검증, 본처리, 종료처리, 예외처리의 기본구조를 가지도록 한다.

2레벨에서 예외처리는 처리내용이 간략할 경우 VM으로 처리할 수 있다.

다음은 기본 템플릿 디자인의 예이다.

figure3 11
온라인 프로그램 기본 템플릿 예

EMB 모듈을 디자인할 때 다음의 사항을 고려해야 한다.

  • 5단계 레벨 내에서 디자인한다.

  • 초기처리, 입력검증, 종료처리, 예외처리 형태로 생성한다.

    • 비즈니스 로직이 없더라도 형태는 유지한다.

    • 예외처리는 정상적으로 종료되지 않는 경우에 수행되는 로직을 구현한다.

  • 2레벨에는 IM을 배치한다. (예외처리는 제외한다.)

  • VM을 너무 작은 단위로 나누면 EMB 모듈의 흐름파악이 어려울 수 있다.

  • VM이 연속으로 나열되는 것은 권하지 않는다.

  • 논리명은 모듈의 성격에 맞게 입력하여 가시성을 높인다.

  • 논리명이 길 경우 공백으로 분리하여 자동으로 줄을 바꾼다.

  • IM의 하위노드가 VM 하나인 경우는 권하지 않는다.

  • 차후 IM은 'function'으로 VM은 'block'으로 설정한다.

  • 논리분기는 XOR 처리한다.

  • 온라인 프로그램 내부에서 반복되는 VM은 VF로 작성한다.