저는 개발 역할의 일부로 BizTalk 응용 프로그램을 지원하고 제작하는 것을 계승 받았습니다. 나는 일반 C# 개발자이므로 Class를 만들고 Orchestration의 Expression 셰이프에서 Methods를 호출 할 수있어서 기뻤습니다. 즉, BizTalk 방식을 익히는 대신 친숙하고 빠르게 코드를 사용하여 모든 데이터 조작을 수행 할 수 있습니다.BizTalk 오케스트레이션에서 클래스 및 메서드 사용
이 시점에서 나는 그것이 좋은 생각인지 아닌지에 관심이 없습니다.
이렇게하지 않아야하는 기술적 인 이유가 있습니까?
호출하려는 외부 메서드가 다중 스레딩이 가능하고 높은 처리량을 처리 할 수 있는지 확인해야합니다.
위의 사항을 달성하지 못하면 크로스 스레드 오염으로 인해 발생하는 매우 이상한 문제가 발생하거나 메시지 처리량을 줄이는 BizTalk 병목 현상이 발생할 수 있습니다.
또한 오류가 발생하면 다시 호출 오케스트레이션에 오류가 처리되고 다시 시도되고 전파되는지 확인해야합니다. 어떤 이유로 개발자가 외부 클래스를 사용하여 웹 서비스를 호출하기로 결정한 한 솔루션을 발견했습니다. 모든 경우에이 웹 서비스는 오류를 던질 것이지만, 유효한 응답 메시지 인 것처럼 오케스트레이션에 돌아 왔을 때 클래스는 오류 메시지를 전달합니다. 오케스트레이션에서 나중에 메시지를 사용하려고했지만 예상 한 메시지와 일치하지 않을 때 오류가 발생합니다. 할당 된 예산을 얻었을 때이 클래스를 올바르게 구성된 송신 포트로 바꿨습니다. 송신 포트는 웹 서비스 오류가 발생하여 메시지를 자동으로 재 시도 한 다음 성공적으로 처리했습니다.
기술적으로는 외부 어셈블리를 사용하여 배포를 추가하고 복잡성을 유지합니다. 예를 들어 일부 계약의 변경 사항에는 어셈블리와 오케스트레이션이 변경되어야합니다. 그리고 일반적으로 쉽게 배울 수있는 데이터 변환을 위해 BizTalk 매핑 엔진의 모든 이점을 잃어 가고 있습니다.
감사하지만이 대답은 프로세스와 유지 관리 가능성에 관한 것입니다. 이 기술로 BizTalk 기능이 중단되는지 확인하는 데 관심이 있습니다. – Richard210363
@ Jonhs-305가 전에 논평했듯이, 아무 것도 깨뜨리지 않고 있습니다. –
"BizTalk Way"로 BizTalk 응용 프로그램을 개발하는 것이 향후 유지 관리에 매우 중요합니다.
예를 들어 Map 또는 XPath에서 수행해야하는 외부 클래스에서 메시지 조작을 수행 한 경우 코드 검토에서 리팩토링을해야합니다.
이유는 누구든지 BizTalk 응용 프로그램을 기대해야하기 때문입니다. 지금까지 개발자가 BizTalk 및 외부 프로세스를 수용해야하기 때문에 설명하는 상황을 보았지만 새로운 비즈니스 요구 사항을 업그레이드, 향상 및 지원하기가 더 어려워졌습니다.
감사하지만이 대답은 프로세스와 유지 보수성에 관한 것입니다. 이 기술로 BizTalk 기능이 중단되는지 확인하는 데 관심이 있습니다. – Richard210363
외부 메서드 호출이 지원됩니다. 그것은 '아무것도 깨지 않는다'. 미래에 가장 쉬운 (가장 비용이 적게 드는) 방법을 수행하는 것을 막을 위험이 높습니다. 이 경우 BizTalk Dev 패턴이 손상됩니다. –
기술적으로 .NET 클래스를 사용하면 BizTalk에서 아무 것도 손상되지 않습니다. 많은 BizTalk 구성 요소는 어댑터, 파이프 라인 구성 요소 등과 같은 .NET 프레임 워크를 기반으로합니다. 내 생각에 시나리오에 따라 BizTalk 및 .NET의 장점을 모두 사용하십시오. 예 : 인바운드 XML을 아웃 바운드 XML에 매핑해야하는 경우 BizTalk 맵을 훨씬 쉽고 빠르게 구현할 수 있으므로이 시나리오에서는 .NET 클래스를 사용하는 것이 맵을 사용하는 것이 지루합니다. 지도, 오케스트레이션, 파이프 라인 구성 요소와 같은 BizTalk 기능을 사용하는 데 큰 학습 곡선이 있다고 생각하지 않습니다.
명확한 설명에 따르면 "기술적으로"이 작업을 수행 할 때 BizTalk가 중단되는 영역을 식별하는 대답을 찾고 있습니다. – Richard210363