(deutsche Version weiter unten)
BizTalk RFID integration too slow?
I heard discussions that BizTalk RFID is too slow when integrating with "regular" BizTalk.
It is true that when you use only "out-of-the-box" components, you might end up building a solution like that:
- transactional BizTalk RFID process
- BizTalk RFID SQL Server Event Sink
- BizTalk SQL Server Adapter
- ... regular BizTalk Server processing
Because of several reasons this is a "slow" approach: Biztalk RFID works "transactional", adding overhead. BizTalk RFID pushes data to the database. Then the BizTalk SQL Server Adapter needs to poll the database to retrieve the data, depending on the polling interval.
If speed is a concern, then consider carefully if you need transactional integrity or reliability at the process level. The "express" option can speed the process up with the risk of missing some events. Next, it is not a good idea to have a coupling between BizTalk RFID and regular BizTalk that is dependend on polling. A better approach is to use a BizTalk WCF adapter and write your own event handler that posts to that adapter. This means that BizTalk can "kick in" immediately when the message gets sent to BizTalk. Couple that with approaches that avoid the message box and the speed issues should go away while leveraging the BizTalk platform.
The "fastest" way of course would be to implement the system connectivity directly in the event handler. However, try to keep the event handler as lightweight as possible and rather ship the processing out to another box, interfacing in a way that allows load balancing. Here, again WCF is a good guess since it allows you to retain most of the loose coupling you might need.
In my opinion WCF is the most practical approach to connect systems with BizTalk RFID.
BizTalk RFID Integration zu langsam?
Ich bekam einige Diskussionen mit, dass die Integration von BizTalk RFID mit der normalen BizTalk Infrastruktur zu langsam wäre. Wenn man nur die mitgelieferten Standardkomponenten nutzt, kann es tatsächlich passieren, dass man zu einer Lösung kommt, die ungefähr wie folgt aussieht:
- transaktionaler BizTalk RFID Prozess
- BizTalk RFID SQL Server Event Sink
- BizTalk SQL Server Adapter
- ... normale BizTalk Server Verarbeitung
Aus verschiedenen Gründen ist das ein "langsamer" Lösungsansatz: BizTalk RFID arbeitet hier "transaktional", was einiges an Overhead bedeutet. Dann schreibt BizTalk RFID die Daten in eine Datenbanktabelle. Der BizTalk SQL Server Adapter muss diese Tabelle regelmäßig abfragen, was dazu führt, dass die Geschwindigkeit wieder vom "Polling Intervall" abhängt.
Wenn Geschwindigkeit von Bedeutung ist, sollte man hingegen genau prüfen, ob transaktionale Integrität oder "Reliability" wirklich auf der Prozessebene gefordert sind. Die "Express"-Option kann den Prozess beschleunigen, birgt aber das Risiko, dass Events verloren gehen. Der nächste Punkt ist, dass eine Kopplugn zwischen BizTalk RFID und dem "normalen" BizTalk, welche auf einem Polling-Mechanismus basiert, keine sonderliche gute Idee ist. Ein besser geeigneter Ansatz ist, den BizTalk WCF Adapter zu verwenden und einen eigenen Event Handler zu implementieren, der an diesen Adapter sendet. Dies führt dazu, dass BizTalk sofort mit der Verarbeitung anfangen kann, wenn die Nachricht an Biztalk gesendet wird. Wenn man dies mit Ansätzen verbindet, welche die Verwendung der Message Box vermeiden, kann man Geschwindigkeitsprobleme umgehen und dennoch die Vorteile der BizTalk Plattform ausnutzen.
Der "schnellste" Weg wäre natürlich, die Systemanbindung direkt innerhalb des Event Handlers zu implementieren. Dieser Event Handler soll aber so leichtgewichtig wie möglich bleiben und eher die Verarbeitung an ein anderes System auslagern, wobei das andere System in einer Art und Weise verbunden werden sollte, welche eine Lastverteilung ermöglicht. Auch hier bleibt WCF ein guter Ansatz, da es erlaubt eine möglichst lose Kopplung beizubehalten.
Fazit: Nach meiner Meinung ist WCF der praktikabelste Ansatz, um Systeme mit BizTalk RFID zu verbinden.
Posted
May 30 2007, 10:40 PM
by
Andreas Erben