문제

Biztalk ESB 툴킷 2.0 사용

우리는 DLL 인 웹 서비스로 프록시를 호출 해야하는 프로젝트를 진행하고 있습니다. 정적 포트를 사용하고 Biztalk Admin 인터페이스의 어셈블리를 가리키는 웹 서비스 설정과 함께 SOAP 어댑터를 사용할 수 있도록 구성 할 수 있기 때문에 오케스트레이션을 통해이 작업에 아무런 문제가 없습니다. 동적 포트에는 비누 어댑터를 사용할 옵션이 없기 때문에 여정에서는이 작업을 수행하는 명백한 방법이없는 것 같습니다.

우리 가이 일을하고 싶은 이유가 있습니다. 걱정하지 마십시오.

이후, 우리는 사용자 정의 어댑터 제공 업체를 구현했지만 작동하는 데 문제가 있습니다.

우리는 표시된 (오래된) 예를 따랐습니다 여기:

사용자 정의 어댑터 제공 업체는 BaseadapterProvider에서 상속하고 설정 점 (Dictionary, IbasemessageContext) 메소드를 무시합니다.

이 방법은 Resolver Dictionary를 통해 전달되는 어셈블리 이름, 유형 이름 및 메소드 이름을 추출한 다음 파이프 라인 컨텍스트에 씁니다.

pipelineContext.Write("TypeName", 
    "http://schemas.microsoft.com/BizTalk/2003/soap-properties", typeName);
pipelineContext.Write("MethodName", 
   "http://schemas.microsoft.com/BizTalk/2003/soap-properties", action);
pipelineContext.Write("AssemblyName", 
    "http://schemas.microsoft.com/BizTalk/2003/soap-properties", assembly);

운송 유형을 비누로 설정합니다.

pipelineContext.Write("TransportType",
    "http://schemas.microsoft.biztalk.practices.esb.com/itinerary", "SOAP");

다른 모든 측면에서, 어댑터 공급자는 SMTP에서 SOAP로의 명백한 변화를 제외하고 위의 링크에 표시된 예와 거의 동일하다.

어댑터 제공 업체 어셈블리에 서명, 게재 및 ESB.config에 추가됩니다.

어댑터 제공 업체는 일정에서 서비스를 호출 한 다음 응답을 반환하는 여정에서 호출됩니다. 우리는 툴킷과 함께 배송되는 여정 테스트 클라이언트에서 여정을 테스트하고 있습니다. 사용자 정의 어댑터 내의 이벤트 로깅은 어댑터 코드가 호출되고 있음을 보여줍니다. 문제는 메시지가 서비스 프록시로 라우팅되지 않는다는 것입니다. 이벤트 뷰어는 다음과 같은 오류를 나타냅니다.

메시징 엔진은 어댑터에서 제출 한 메시지를 처리하지 못했습니다 : SOAP 소스 URL : /esb.itineraryServices.response/processitinerary.asmx. 세부 사항 : 가입자가 발견되지 않았기 때문에 게시 된 메시지를 라우팅 할 수 없습니다. 이 오류는 가입 오케스트레이션 또는 보내기 포트가 입대되지 않았거나 구독 평가에 필요한 일부 메시지 속성이 홍보되지 않은 경우에 발생합니다. Biztalk Administry Console을 사용 하여이 실패를 해결하십시오.

그룹 개요에서 일시 중단 된 서비스 Instamces를 조사하면 어셈블리 이름, 유형 이름 및 메소드 이름의 값이 올바르게 설정되고 있습니다. 메시지 본문이 누락되었습니다. XMLTRANSMIT/XMLRECEIVE 및 ETINERARYSENDPASSTHROWH/PASSTHROWHECEIVE를 모두 보내기 위해 보내기 포트에서 보내기 파이프 라인을 구성하려고 시도했으며 아무런 차이가 없습니다.

우리가 놓친 분명한 것이 있습니까? 메시지 본문을 명시 적으로 통과해야합니까? 그렇다면 어떻게?

편집하다:

다음 a Biztalk ESB 툴킷 포럼에서 요청하십시오 여정, 컨텍스트 및 포트 필터를 보내는 스크린 샷을 게시하고 있습니다.

여정, 문맥, 포트 필터.

많은 감사합니다, Nigel.

도움이 되었습니까?

해결책

우선 솔루션을 과도하게 엔지니어링하려고한다고 말할 것입니다. 어댑터 개발은 사소하지 않으며 고려해야 할 다양한 것들이 있습니다. 어댑터 개발 및 배포는 플랫폼 변경으로 분류되어 전체 환경에 영향을 미치므로 익숙하지 않은 경우 수행하지 않아야합니다. 다른 길을 택하는 것이 좋습니다. 이 시점에서 나는 개인적으로 ESB 내부에 대한 통찰력이 충분하지 않으므로 댓글을 달 수 없습니다. 최악의 경우 어댑터를 구축하지 않고 오케스트레이션 (표현 또는 메시지 모양) 내부의 .NET 프록시 DLL을 사용하는 것이 좋습니다. 권장되는 접근 방식은 아니지만 여전히 사용자 정의 어댑터 접근 방식보다 낫다고 생각합니다.

다른 팁

의미 적으로, WCF-BasicHTPP 어댑터와 관련된 솔루션이 시나리오에서 작동하지 않는 이유를 알 수 없습니다. 어쨌든, 나는 WCF-BasichTTP 어댑터에서 어떤 일이 일어나는지 확실히 보려고 노력할 것이며, 일단 작동 솔루션을 얻으면 실제로 필요한 경우 사용자 정의 비누 어댑터로 전환 할 것입니다.

현재 솔루션은 이상합니다. 오프 램프에 직접 연결된 램프가 있다는 의미에서. 나는 내 여정에서 그것을 본 적이 없다. Betweeen에서 중간 메시징 또는 오케스트레이션 여정 서비스를 만들어야 할 수도 있습니다.

그렇지 않으면 메시지가 효과적으로 메시지 상자에 게시되고 분명히 가입자가 없으므로 오류가 발생합니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top