EAI 그리고 SAP PI, PO

📌들어가며..

학부생 시절 개발 경험을 빗대어 생각해본다면 전체 서비스를 구성하기 위해 Application을 최소 단위로 작게 만들어 MSA 구조로 서비스를 지원한다. 이때에 각 서비스(Application)간 통신 즉, 데이터를 주고 받으며 Application을 연동, 통합 하는 과정을 생각 해본다면 단순히 HTTP, HTTPS를 사용하며 REST API를 호출하여 통신(연동, 통합) 할 것이다. 조금 더 생각한다면 AWS에서 배운 API Gateway를 배치하여 Application간 통신을 관리 한다는 정도이다.

하지만 이것은 모두 Web Server로 구성된 아키텍쳐에서 REST API 형식으로 통신 한다는 가정이 들어가는 것이다. 통신에는 REST API 뿐만 아니라 많은 형식이 존재하고, 실제 현업에서는 같은 Web Application간 통신도 무조건 REST API 형식이 아닌뿐더러 Web Application만 존재하지 않은 시스템 아키텍쳐가 더욱 많다. 이때에 우리는 각 Application간 통신을 지원하고 이것을 관리하는 방법에 대해서 생각해 볼 필요가 있을 것이다.

📌EAI 이전, Point-to-Point

시스템들이 업무 단위로 분리되고 각 업무에 적합한 Application으로 적용 되면서 전체 시스템은 한 덩어리에서 잘게 나누어지게 되었다. 이때 각 시스템은 서로 필요에 의해 통신 되면서 HTTP, FTP, RFC, Socket, DB Link등 통신 Protocol을 Application 간 직접 연결하였다.

10개 전체 시스템의 개별 통신을 지원하기 위해 P2P로 직접 연결 한다면 N(N-1)/2에 의해 45개의 연결을 개별 Applicationd에 적용 해야한다.
시스템은 더욱 구체적으로 나누어지며 확정 됨에 따라 세부 시스템간 P2P 연결 통신 구조는 한계에 다다르기 시작했다. 단순히 연결 갯수를 증가하는 것에 문제가 아니라, 변경 사항에 있어서 연관 된 P2P를 관리하고 유지보수 하기가 어렵게 되었다.

📌EAI

이러한 문제점을 해결하기 위해 EAI가 등장하여 Application간 통합, 통신을 지원하게 되었다.

EAI(Enterprise Application Integration)은 중앙 허브를 통해 모든 통신은 EAI를 거치며 개별 시스템마다 Adapter를 통해 통신을 지원한다. 따라서 각 시스템은 EAI와 연결만 유지하고 타 시스템과의 연결은 EAI를 통해 통신되기 때문에 EAI와의 연결만 유지하고 타 시스템의 변경사항에 자유롭다는 이점이 생겼다.

하지만 소규모 시스템에서는 P2P보다 필요 이상의 개발 비용이 발생한다는 단점으로 인해 초기 EAI 개념을 확장한 ESB, API Gateway 등으로 확장된다.

EAI More

하지만 EAI는 어디까지나 하나의 개념일 뿐이며 시스템 아키텍쳐의 표준은 아니기 때문에 특정 구조로 한정하기가 어렵다.

모델 통합 측면에서 Messaging Bus 유형으로 EAI를 구성한다면 그것이 바로 EAI를 확장한 ESB개념이 되는 것 처럼 EAI 자체를 하나의 특정 구조로 한정 짓기는 어렵다. 실제로 현업에서는 EAI, ESB, API Gateway든 같은 시스템 내부에서 Application간 통신을 관리하고 지원하는 미들웨어를 전부 통틀어 EAI라고 부르기도 한다.

---

📌SAP PI

SAP PI(Process Integration)는 SAP에서 제공하는 EAI 중앙 집중식 통합 플랫폼이다. SAP PI는 HTTP, FTP, SOAP, XML, RFC등 디양힌 통신 Protocol을 지원하지만 Java 기반 시스템과의 연동만 지원한다. 다양한 시스템과 연동을 위한 어댑터를 제공하고, 그외에도 데이터 매핑, 프로세스 모니터링, 보안 기능과 SAP BPM(Business Process Management) 기능을 제공한다.

BPM(Business Process Management)
업무 프로세스에 연관된 사람, 데이터, 시스템 및 전체 프로세스를 관리해주어 신속하고 빠른 의사결정을 할 수 있도록 도와준다.

📌SAP PO

SAP PO(Process Orchestration)는 SAP PI의 후속 제품이며 보다 강력한 Application 통합 기능을 제공한다. 추가적으로 SAP BRM(Business Rules Management) 기능을 통해 비즈니스 규칙 관리를 지원한다.

BRM(Business Rules Management)
다양한 의사결정 논리를 정의, 수행, 감시 및 유지보수하고 비즈니스 규칙을 관리하여 비즈니스 프로세스를 효율적으로 유연하게 만들 수 있게 도와준다.

• BRM 적용 사례
  버거킹 가맹점 관리 시스템은 BRM을 통해 가맹점들을 효과적으로 관리하고 운영한다. 가맹점에 필요한 매출, 재고, 인사 관리 등과 같은 비즈니스 규칙 표준을 제공한다. 예를들어 특정 매출 목표를 달성하기 위한 할인 정책, 재고관리, 인사 정책들을 제시해준다.

---

SAP PI/PO More

SAP 공식 홈페이지를 살펴보면 SAP PI, PO의 차이점을 기술적으로 서술한다. 가장 큰 차이점은 SAP PI는 이중 스택 설치로 Java와 ABAP 스택 모두를 설치해야 하지만, SAP PO는 Java 전용 독립 스택으로 단일 스택 설치를 지원한다. 하지만 이런 이중 스택과 단일 스택의 구체적인 차이점과 장단점에 대해서 이해하기 힘들었을 뿐만아니라, SAP PI 버전의 발전으로 인해 SAP PO 처럼 단일 스택을 지원하는 버전도 있다. 따라서 SAP PI/PO간 명확한 구분은 힘들었기 때문에 위의 내용 처럼만 구분 하고자 한다.

참고 및 출처
https://bcho.tistory.com/1292
https://blog.skby.net/eai-enterprise-application-integration/
https://sheerheart.tistory.com/entry/EAI-%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80
https://inspien01.tistory.com/102
https://blogs.sap.com/2012/01/11/installation-options-for-process-integration-and-orchestration-use-cases/