[XI/PI] BPM 기본 매뉴얼

1) BPM (Business Process Model) 은 인터페이스의 확장이라는 개념으로 생각해야 됩니다.

    단순히  송신 시스템 -> EAI (PI/XI) -> 수신 시스템의 일반적인 인터페이스 흐름에 비해

    BPM을 쓰게 되면 송신 시스템 -> EAI (--> BPM --> EAI) -> 수신 시스템의 흐름을 가지게 됩니다.

2) BPM에서 할수 있는 것은 저수준의 로직 처리, 분기 처리, 변수값 조작, ID의 정보 접근, 데이터 gathering, 송수신 등이 대표적입니다.

3) BPM 내부에서는 비지니스적인 처리가 가능하다는 점에서 기존의 인터페이스의 확장된 개념입니다.

 기존의 인터페이스에서 Integration에서는 해당 데이터가 어느 business system으로부터 어떤 데이터가 왔는지 ID에서 판단해

 해당되는 IR의 인터페이스를 호출해 맵핑 및 데이터 가공, 로직을 수행후 수신받아야 하는 business system으로 전달해주는것이 일반적인 흐름입니다.

 BPM이 사용될때의 흐름인데  business system으로부터 어떤 데이터가 왔는지 ID에서 판단하는 부분은 기존의 인터페이스와 동일하지만 인터페이스

호출대신 BPM이 실행되면서 BPM에 그려진 순서대로 비지니스를 처리합니다. BPM 내부에서는 ID에 설정이 된 Sender 혹은 Receiver 갯수만큼 

레거시, 파트너로 송수신이 가능합니다.

  1) BPM은 인터페이스가 확장된 개념이므로 맵핑과 인터페이스의 기능도 있습니다.

      IR에서 다루는 개체와 BPM에서 다루는 개체를 연결해 보면

                               BPM          :   Interface

       (1) Receiver or Sender step = Service Interface

 

       (2) Transformation step       = Operatin Mapping

  2) 그리고 Receiver or Sender step은 ID에서 설정한 Business Partner와 연결이 되어 있습니다.

   1) 위 화면은 BPM 구성을 위한 객체인 Integration Process를 생성했을때 오른쪽 하단에 보이는 Container 화면입니다.

   2) Integration Process에서의 순서도에 쓰인 개체에서 참조할수 있는 변수명 혹은 abstract interface는 반드시 Container에 등록이 되어있어야 합니다.

   3) 만들수 있는 개체는 위의 그림에 나와있는 대로입니다.

       (1) simple type : 해당 BPM 인스턴스간에 변수로써 사용이 됩니다.

       (2) abstract interface : 송수신 시의 Message Type가 지정된 abstract interface 입니다. 

    Integration Process에서는 Interface, Message 두가지의 의미로 사용됩니다.

 (3) Receiver : ID에서의 수신자 정보를 가집니다. Receiver Determination step 을 통하여 만들어집니다.

  4) 맨 앞열은 사용여부, 변수 구분을 나타냅니다.

       (1) 파란 삼각형 : BPM간 전역 변수로 사용됩니다.

       

       (2) 빨간색 오른쪽 위의 삼각형 : BPM 어디에선가 사용되고 있다는 의미입니다.

       (3) 굵은 줄 아래의 파란 삼각형이 없는 것 : BPM간 지역 변수로 특정 Block step 아래서만 사용할수 있습니다.

  5) Multi line 이 체크된  abstract interface는 해당 인터페이스가 취급하는 Message Type이 다량으로 있을수 있다는 의미입니다.

  6) Scope에 설정된 것은 해당 Container 객체가 유효한 범위를 나타냅니다.

1) Correlation 이란 두 개 이상의 Message간의 연관 관계를 의미합니다. 다음의 경우를 생각해 봅시다.

    어느 BPM은 첫번째 메세지와 두번째 메세지를 두 파트너로부터 받은 다음에 진행하는 로직을 가지고 있습니다.

    1. 파트너 1은 메세지 A,C를 보내왔습니다.

    2. 파트너 2는 메세지 B,D를 보내왔습니다.

    3. 들어온 순서는 A,B,C,D의 순서이고 비지니스상으로 A와 D가 같이 처리해야하는 데이터이고 B,C가 같이 처리할 쌍입니다,

    4. 들어온 순서에 따라 B까지 데이터가 들어왔을때 BPM은 두개의 인스턴스를 가지고 있습니다. A에 의해 발생한 것과 B에 의해 발생한 것

    5. 메세지 C가 들어왔을때 이것은 B에 의한 인스턴스로 가서 쌍을 이루어야합니다. 메세지 D는 A에 의한 인스턴스로 가야됩니다.

   이경우 무슨 기준으로 C을 B에 의한 인스턴스로 보낼까요?

   "C의 특정 필드와 B의 특정 필드가 같아서 두 데이터는 같이 처리해야 될 데이터 임을 확인해야합니다"

2) 위에서 말한 특정 필드를 정의한 것이 Correlation 입니다.

3) Correlation은 특정 요청에 대한 응답을 찾을때, 같은 데이터를 같이 처리하기 위해 gatering 할때, 두 개이상의 파트너로부터 같이 처리할 데이터를 받을때  

   사용합니다.

  

    

    ID의 Sender와 연결되는 개체 입니다. 모든 BPM은 receive step으로부터 시작합니다.

    ID의 Receiver와 연결되는 개체로 다른 비지니스 파트너에게 송신합니다.

        하나의 문서를 다른 문서로 포맷 변환하는 서비스입니다.

          조건식의 변수로 사용될수 있는 것은 메세지의 특정 필드 혹은 container에 simple type으로 선언된 개체만 가능합니다.

   

         1) Integration Process의 설정이 끝나고 ID를 설정할때 제일 먼저 할것은  Integration Process의 임포트입니다.

         2) 임포트가 성공하면  Integration Process 개체가 시나리오 상에서 보입니다.

         3) ID에서  Integration Process는 business partner의 개념으로 취급됩니다.

       예)  하나의 BPM에 다음의 시나리오가 있다고 가정합니다.

             1. 웹서비스로 호출받음.

             2. 호출받은 파라미터로 DB에 insert.

             3. 호출받은 파라미터를 FTP 전송

             4. 처리결과를 DB에 반영.

     이경우 Sender 채널은 1개

         1) 비지니스 파트너 ----(웹서비스)----> BPM(receiver step)

    

     그리고 Receiver 채널은

 

         1) BPM(sender step) ----(DB Insert)----> 비지니스 파트너(DB)

   2) BPM(sender step) ----(FIEL)----> 비지니스 파트너(FTP)

         3) BPM(sender step) ----(DB Update)----> 비지니스 파트너(DB)

   이렇게 4개를 설정해야하지만 Receiver 채널중에 1)과 3)은 똑같은 JDBC adapter를 사용하므로 하나만 있어도 됩니다.

   그러므로 총 1개의 Sender 채널, 2개의 Receiver 채널이 있으면 됩니다.

        Community component에 있는 Communication component에 ID 설정 최초시에 등록한 BPM을 지정해주면 됩니다.

         위의 설정을 통해 인터페이스 대신 BPM을 구동할수 있습니다.