우리는 독립형 Java 응용 프로그램에서 SAP R3와 통신하려고합니다. 우리는 JCo 3.0 라이브러리를 사용합니다.SAP JCo 클라이언트 대 서버
문서에서 SAP와 연결할 수있는 두 가지 방법이 있다는 것을 이해했습니다. JCO 클라이언트 JCO 서버 처음에는 우리의 응용 프로그램이 JCO 클라이언트로 연결해야 할 것이라고 확신했다에서
로
우리의 응용 프로그램 은 데이터을 보냅니다. (예 : 주문 상태 업데이트) 그러나 Google 에도 데이터이 전송됩니다 (예 : SAP가 마스터 데이터의 변경 사항을 MATMAS에 푸시).
그래서 클라이언트 또는 서버 여야합니까?
JCo 3.0 API 모델에는 아니지만 JCoDestinations 인 JCo 클라이언트가 없으며 대신 2.135 API 모델의 이전 JCO.Client을 대체했습니다. 은 RFC 프로토콜을 통해 SAP에 연결하는
그리고 2 가지 방법은 다음과 같습니다
인바운드 RFC의 경우 ABAP 측에서 원격 기능 모듈을 실행하려면 JCoDestination을 사용해야합니다. 아웃 바운드 RFC의 경우 SAP 게이트웨이에 JCoServer을 등록해야합니다. 그러면 SAP 측에서 ABAP 측으로부터 들어오는 요청을 수신하여 Java 측에서 원격 기능 모듈을 처리합니다. 두 통신 방향 모두에서 요청이 있고 잠재적으로이 요청에 대한 응답이기도하므로 인바운드 및 아웃 바운드 RFC 통신을 위해 데이터 흐름이 양방향입니다. 인바운드 및 아웃 바운드는 누가 RFC 호출을 시작 하는지를 구분합니다.
그리고이가 ABAP 백엔드에서 필요한 RFC 메타 데이터를 쿼리에 대한 기본 JCoServer에서 필요로하기 때문에 JCoServer에 대한, 당신은 일반적으로 또한 저장소뿐만 아니라 일부 JCoDestination를 정의 할 필요가있다. 이러한 이 없으면 JCoServer은 들어오는 RFC 요청 데이터를 해석 할 수 없습니다. 따라서 일반적인 JCo 서버 시나리오에서는 JCoServer 및 JCoDestination (서버의 경우 JCoRepository)이 필요합니다.
두 사례 (클라이언트 호출 및 저장소 쿼리) 모두에 대해 JCoDestination에 대해 동일한 구성을 사용할 수 있지만 SAP는 연결 풀 크기의 정의와 관련하여보다 유연한 별도의 구성을 정의하고 두 가지 모두에 대해 별도의 RFC 권한을 허용합니다 사용 사례.
둘 다. 실제로 서버 연결을 시작하려면 클라이언트 연결이 필요하므로 서버 연결을 설정하면 클라이언트 연결도 자동으로 연결됩니다.
클래스가 더 이상 클라이언트가 아닌 경우에도 클라이언트의 기능은 여전히 클라이언트로 작동합니다. – vwegert
@vwegert : 의미 상 클라이언트와 대상의 차이점이 있습니다. 예전의'JCO.Client'는 구체적인 RFC 연결을 나타냅니다. 새로운'JCoDestination'은 ABAP 측에서 트랜잭션 SM59에 정의 된 대상처럼 추상 대상 시스템을 나타냅니다. – Trixx
나는 부분적으로 @vwegert에 동의합니다; 제 생각에'JCODestination'은 여전히 클라이언트입니다. SAP는 JCODestination의 사용법을 설명하기 위해 예제 Java 파일을 제공하며,이 예제를 "단계별 클라이언트"라고 부릅니다. - 다른 한편으로 나는 당신이 당신의 대답에 공식화 한 방식을 좋아합니다. "client"라는 단어를 사용하는 것이 레거시 클래스를 참조 할 수 있으므로 혼동을 줄 수 있음을 명확히 설명합니다. - 이제부터는 "인바운드"및 "아웃 바운드"라는 단어를 사용하겠습니다. – bvdb