Biztalk를 사용하고 있습니까? 그렇다면 어떻게 사용하고 있습니까? [닫은

Question

마지막 고용 장소에서 나는 BTS를 상당히 사용했습니다. 그러나 관리자는 종종 잘못된 것을 사용하기를 원하며 개발자는 그것을 채택하는 것을 주저합니다.

그래서, 나는 단지 BTS가 어떻게 사용되고 있습니까? 이론이 아닌 경험을 게시하십시오. 감사!

Answer 1

저는 유럽에서 가장 큰 석유/에너지 회사 중 하나의 컨설턴트로 일했으며 기본적으로 모든 메시징/통합 제품에 Biztalk를 사용합니다. 예는 다음과 같습니다. 송장 (전자 송장)은 다양한 형식의 파트너에서 및 파트너에게 전송되며, 자체 사용자 이름 DB를 유지하고 전자 메일을 통해 지원 시스템과 외부 고객 간의 통합을 유지하는 AD와 타사 소프트웨어간에 작업을 동기화합니다. 따라서 Biztalk를 꽤 광범위하게 채택하고 5 개의 서버 클러스터를 사용합니다.

Answer 2

We have a few dozen applications that need to interact. We have a single web service based application which controls passing messages between systems. Other systems talk to it and receive messages from it via BizTalk orchestrations etc.

Answer 3

We do use BizTalk to connect up to a third party ordering system. I would probably classify this as a useful, yet beginner approach to using the vast capabilities BizTalk seems to offer. By this, I mean we only use a fraction of the functionality. It goes something like this:

• An orchestration polls a third party IBM message queue.
• This queue holds order information (in xml format) that we eventually need to import into our Microsoft SQL Server Database.
• Once the xml is received from the queue we run a xslt translation to get the xml into a format that our system understands.
• With the translated xml we end up calling a stored procedure which does the the actual "importing" of the order.

The solution ended up working fairly well and has been in production for a few years now. It's one of those things that just works.

One thing I would note is that while developing this we tried to use the Mapper tool to help us with the translation part of things. Our translation was quite complicated and the tool itself was super tedious to use. Since we were comfortable with xslt we ended up writing our own and not using the graphical Mapper tool. It seems that the Mapper tool would be very useful for simple translations, but anything over a handful of elements starts to become a maintenance nightmare (IMHO).

Answer 4

In the past I've used BT (2004) for ecommerce purposes (ordering, order acknowledgement, delivery notification, etc) in a B2B environment and it worked really well. This is probably the bread-and-butter of BT in that it is the most obvious place for it to sit in an organisation.

These days I'm (almost) involved in an entirely internal BT project that is initially handling a massive data-load from a legacy system into a new app, and going forward will handle the messaging between another legacy app and the same new system. Probably not the most efficient use of technology, but the infrastructure is now in place to implement an Enterprise Service Bus type architecture that is viewed as "the saviour of our business". I've yet to be convinced on that thinking, though. :S

Answer 5

We currently use BizTalk 2006 at our company for communicating orders from a Commerce Server 2007 instance and a host of stores that are all running Dynamics RMS to our main ERP, Dynamics NAV. BizTalk is certainly a powerful solution but I do consider the learning curve fairly steep and agree with others on StackOverflow that have said it is the most complicated server produced by Microsoft.

For what it does it is rock solid and if there have ever been problems with the system it has been on one end of the chain or other other but never with BizTalk.

Answer 6

We use BizTalk 2006 for importing small and large data files from various sources and of various types (CSV, fixed width, XML). I think one of the great features of BizTalk is its Flat File Disassembler. You can describe the makeup of a flat file using a wizard and this representation is stored as an XML Schema Definition (.XSD). The wizard even allows you to decipher a single file that may contain rows of varying type (and hence length) based on some indicator on the line itself. Cool stuff.

-Krip

Answer 7

At my company we use BizTalk as a massive document translation engine. We do EDI, XML and Flat File processing for supply chain docs. We are acting in a document broker scenario and use BT to receive documents in any format and then transform them to any other format to be routed on to any trading partner.

So instead of each pair of two trading partners going through an EDI onboarding exercise, we onboard each trading partner to their specications and then use our translation engine to ensure that they can send and receive their documents in a static format. Internally we map their format to a canonical schema and then plug and play trading partners between one another. Think of a hub and spoke document network.

Answer 8

Personally have developed for:

Procurement: handling buying request for a hospital to different manufacturing companies. These companies would have varying xml requests sent out to different companies, where each manufacture will have it's own style. All purchases then were also made into a html/xslt report (in house receipt) showing what was bought at what prices.

HL7: Handle a huge amount of HL7 files being processed at once (think it was setup to handled 4 at a time), processed and placed into a new folder for that day.

Answer 9

I developed some Hl7 solutions using the HL7 Accelerator,managing the workflow of a claims application system, integration between disparate systems using a generic approach for message routing, etc.

All good fun and a lot of work... ;-D