인스피언(http://www.inspien.co.kr)

Sender 가 SOAP 일 경우에는 WSDL을 배포해서 호출 하는 쪽에 전달 해줘야 한다. WSDL을 파일을 주던 WSDL URL을 주던...

WSDL파일을 만드는 방법은 크게 두개지로 나눌수가 있는데 간단 한 방법은 아래 그림과 같이 Sender Agreement에서 마우스 오른쪽 버튼을 눌러서

만드는 방식이 있다.

그림과 같이 Sender Agreement에서 "Display WSDL"을 클릭하면

다음 그림과 같이 WSDL을 얻을 수가 있다. 위의 WSDL URL을 개발자에게 줘두 되고

아래 EDIT Box에 있는 WSDL 내용을 파일로 저장해서 보내줘두 된다.

이때 Drag한 부분이 실제 WebService URL이 된다. 총 두개가 있는데 하나는 HTTP URL이고 또 하나는 HTTPS URL이다.

HTTPS URL은 SSL 셋팅이 완료 되어야 사용 할 수 있다.

주의 할점은 아래와 같이 Sender Agreement에 설정 된 채널이 HTTP, SOAP, XI가 아닐 경우 아래와 같은 에러가 발생 한다

    Error Message : "Selected communication channel INSPIEN_FILE2DB_FILESender is assigned to the wrong adapter type File Supported adapter types: HTTP, SOAP, XI, WS."

또 다른 에러로는 Sender Agreement의 Software Component Version of Sender Interface에 값지정 되지 않았을 경우 아래와 같은 에러가 발생한다.

꼭 설정 해주어야 한다.

    Error Message : "No SWCV specified for service interface INSPIEN_FILE2DB_Out; specify a SWCV in Sender Agreement and try again"

두번째 방법으로 메뉴에 "Tools → Display WSDL" 메뉴에 들어가서 하는 방법이다.

Continue를 클릭하고 다음 화면으로 넘어 오면 Channel의 URL을 입력 해야 한다. 여기서 Propose URL을 클릭 하면 엔진 URL로 가게 된다.

실제는 Channel URL로 보내는게 맞다. 우선 Propose URL을 클릭 한후에 추후에 WSDL에서 변경 하도록 하자.

여기서 Outbbound Service Interface의 명을  찾는다. 종이 두장 겹처 놓음 모양의 Icon을 클릭 한다.

WSDL을 만들 Interface를 찾고 Apply를 클릭 한다.

그럼 다음과 같은 화면이 나타난다. Continue를 클릭한다.

다른 값들은 모두 들어 가 있다. 하지만 Communication Component의 값은 비어져 있다. 강제로 입력하자. 그리고 다음..

그럼 끝이다.. Finish

여기서 나온 Text를 복사 해서 WSDL파일로 만들면 된다. 주의 점은 좀전에도 말했지만 해당 URL은 엔진 URL이다. 동작 하는데 이상은 없겠지만

Channel URL로 변경 해주길 바란다.

그냥 첫번째 방법으로 만드는게 속편하다..

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을 구동할수 있습니다.

File Channel에 대해서 설명 드리겠습니다.

Adatper Type에서 File을 선택 하게 되면 다음과 화면이 나타난다.

Transport Protocol : File System(NFS)와 File Transfer Protocol(FTP)를 선택 할 수 있다.

    File System(NFS) = PI Local에 있는 File을 Read할때 사용 하는 옵션 절대 경로를 주면 된다.

    Transfer Protocol(FTP) = FTP로 파일을 가져올때 사용 경로 말고도 접속 정보도 필요하다.(FTPS도 지원)

Message Protocol : File과 File Content Conversion을 선택 할 수 있다.

     File : File을 Read할때 변환 없이 파일 내용을 그대로 읽는다. Mapping 없이 전송할 때나, XML파일을 읽을때 사용

     File Content Conversion : 텍스트 파일을 읽어서 PI가 읽을수 있는 XML형태로 변환 할때 사용한다.

Source Directory : 파일이 존재 하는 실제 경로

File Name : 실제 파일 명 (*.txt, A*.txt 등 표현식이 가능)

    ※ 여러개의 경로가 필요 하다면 아래 Advanced Selection for Source File 옵션을 켜서 여러개 경로를 지정 할 수 도 있다.

        제외 해야 하는 파일명이 있다면 Exclustion Mask에 적어 주면 된다.(ex. *.tmp)

Quality of Service : Best Effort(동기), Exactly Once(비동기), Exactly Once in Order(순서보장 비동기) 를 선택 할 수 있다.

Poll Interval : 얼마마다 파일을 가져 오는지 시간 설정이다. (단위 초)

Processing Mode : Archive(백업), Delete(삭제), Set to Read-Only(읽기전용 변경), Test(읽고 아무것도 안함) 를 선택 할 수 있다.

Add Time stamp : 백업을 선택 했을시 백업 파일명에 Time Stamp 를 붙인다.

Archive Directory : 백업할 경로를 설정한다.

Archive Faulty Source Files : 에러 파일에 대한 백업설정

File Type : Binary형태로 읽을 것인가 Text 형태로 읽을 것인가 선택, Text로 읽을 경우 Encoding을 설정 해야 한다.

Document name : Outbound Interface의 Message type명

Document Namespace : Outbound Interface의 Namespace 명

RecordSet Name : Message Type의 최상위 Document 명 

Recordset Structure : 최상위 Document명 아래 들어갈 Document명들 Setting,

   ※ Document명1,갯수,Document명2,갯수,Document명3,갯수   ex) H,1,D,*

Key Field Name : 여러개의 Document가 있을시 구분을 할 수 있는 Key필드명

옵션들....

   <node>.fieldFixedLengths : FixedLength파일일 경우 각 필드별로 크기를 지정할 때 사용

   <node>.fieldSeparator : 구분자로 필드를 구불 할 경우 해당 구분자값 

      ※ TAB일 경우 그냥 매모장에 TAB을 치고 복사 해서 넣으니 되더군요;;;

   <node>.fieldNames : 필드룰 구분 하고 순서대로 필드명을 넣을때 사용

   <node>.keyFieldValue : 각 node의 Key의 값을 넣어야 함

   <node>.endSeparator : 라인을 구분할때 사용

   <node>.lastFieldsOptional : YES/ NO, 선언한 필드 보다 실제파일의 내용이 적으면 에러가 나는데 이것을 무시하기 위한 옵션

사실 몇개 밖에 쓰지 않지만 많은 옵션들이 있다 다음 URL을 참고 하시길 바랍니다.

http://help.sap.com/saphelp_nw73/helpdata/en/44/6713ec3f914ddee10000000a1553f7/content.htm

Content Conversion에도 설명을 했지만 최상위 Tag와 Document 구조로 구분 되어야 한다. 그렇기 때문에 아래와 같은 구조가 항상 이루어 져야 한다.

파일 관련 Tip

File Channel에서 파일명 가져 오는 방법