Andreas Erben's posts : BizTalk 2006 R2

Don't cache your DeviceConnection in an EventHandler / Eine DeviceConnection sollte man nicht in einem Eventhandler cachen

Andreas Erben — Wed, 11 Jun 2008 08:29:38 GMT

(German version below / deutsche Version weiter unten)

A while ago I talked to someone who knows BizTalk RFID inside out about that sometimes it just takes too long to open a connection to a device in an EventHandler.

The advice I received was, why not caching the connection to the device in the EventHandler, possibly opening it in the in the Init() method and keeping it open.

Out of respect I gave it serious thought and now seriously recommend NOT to do that.

When opening the connection in the Init()-method takes too long or has any slight problems, it will mess up starting up the whole process pipeline.
You would need to build thread safety around it. Though this is not the biggest concern, it is something you should not do.
There is a reason why a DeviceConnection implements IDisposable and allows you to use the using statement.
You effectively disable the chance of any other event handler in another process or even in another piece of software, e.g. a webservice, to access the device normally because you are hogging the connection the whole time.
Connection caching should be implemented by the device provider implementation, because only this piece of software can have appropriate knowledge.
In my opinion mechanisms like connection pooling should be part of the application stack in fact.

There might be isolated cases where it still makes sense to cache a connection in an EventHandler, but those should be pretty rare.

(German version / deutsche Version)

For einiger Zeit unterhielt ich mich mit jemandem, der/die BizTalk RFID in- und auswendig kennt darüber, dass es manchmal einfach zu lange dauert, in einem EventHandler eine Verbindung zu einem Gerät zu öffnen.

Ich erhielt den Ratschlag, warum ich nicht die DeviceConnection im EventHandler cachen würde und sie vielleicht schon in der Init()-Methode öffnen würde und danach einfach offen lassen.

Aus Respekt gegenüber meinem Gesprächspartner habe ich ernsthaft darüber nachgedacht und empfehle nun sehr ernsthaft, dies NICHT zu tun.

Wenn das Öffnen der Verbindung in der Init()-Methode zu lange dauert, oder ein kleines Problem dabei auftritt, wird das den Startvorgang für die ganze Prozess-Pipeline stören.
Man muss um die Verbindung herum eine ordentliche Thread-Safety herum bauen. Auch wenn das nicht das Hauptproblem sein sollte, ist es einfach etwas, was man vermeiden sollte.
Es gibt einen Grund, warum die DeviceConnection IDisposable implementiert und so das using-Statement zulässt.
Man entzieht jedem anderen EventHandler in einem anderen Prozess oder auch einer anderen Software, z.B. einem Webservice, die Chance, selbst normal auf das Device zuzugreifen, weil man die ganze Zeit die Verbindung blockiert.
Eigentlich sollte man Connection Caching in einer Device Provider Implementierung vorfinden, da nur diese "wissen" kann, was das Device wirklich benötigt.
Meiner Meinung nach sollten Connection Pooling Mechanismen auch bei RFID Teil des Applikationsstack sein.

Es mag einzelne, isolierte Szenarien geben, wo es Sinn machen kann, eine DeviceConnection in einem EventHandler zu cachen, dies sollte aber wirklich ziemlich selten erforderlich sein.

Typical setting of IOPorts in BizTalk RFID / Typisches Setzen von IOPorts in BizTalk RFID

Andreas Erben — Mon, 05 May 2008 07:26:34 GMT

(German version below / deutsche Version weiter unten)

When wanting to set an IOPort in BizTalk RFID, to for example switch on a specific light connected to an RFID reader, you basically deal with bits and bytes that you set somewhere. There are typically two ways of how this is implemented in a device:

the device will encode several signal lines in a bitmask in just one port (e.g. implemented by Intermec)
the device will have a port for each and every line (e.g. implemented by Sirit)

Depending on the implementation and your hardware you will have to set a bit to 0 or to 1 to actually activate the line (usually to 1).

So, when wanting to set the second and third line, this could look like this in the first case (e.g. Intermec):

byte[] bitValue = BitConverter.GetBytes(6);
connection.SetProperty("ThePortName",
        StandardDevicePropertyGroups.Source,
        SourcePropertyGroup.PortOutputValue,
        bitValue, null);

and like this in the second case (e.g. Sirit):

byte[] bitValue = BitConverter.GetBytes(1);
connection.SetProperty("PortNameOfLine2",
        StandardDevicePropertyGroups.Source,
        SourcePropertyGroup.PortOutputValue,
        bitValue, null);
connection.SetProperty("PortNameOfLine3",
        StandardDevicePropertyGroups.Source,
        SourcePropertyGroup.PortOutputValue,
        bitValue, null);

(German version)

Wenn man einen IOPort in BizTalk RFID setzen möchte, um beispielsweise ein bestimmtes Licht, welches an einen RFID Reader angeschlossen ist, anzuschalten, hat man vereinfacht gesagt mit Bits und Bytes zu tun, die man irgendwo setzen muss. Typischerweise gibt es zwei Herangehensweisen, wie dies in einem Gerät implementiert ist:

das Gerät kodiert verschiedene Leitungen in einer Bitmaske in nur einem Port (z.B. so durch Intermec implementiert)
das Gerät hat einen Port für jede einzelne Leitung (z. B. so bei Sirit zu finden)

Je nach Implementierung und der vorliegenden Hardware muss man nun den Wert jeweils zu 0 oder 1 setzen, um die Leitung zu aktivieren (normalerweise auf 1).

Wenn man also die zweite und dritte Leitung aktivieren möchte, würde das im ersten Fall (z.B. bei Intermec) so aussehen:

byte[] bitValue = BitConverter.GetBytes(6);
connection.SetProperty("ThePortName",
        StandardDevicePropertyGroups.Source,
        SourcePropertyGroup.PortOutputValue,
        bitValue, null);

und so im zweiten Fall (z.B. bei Sirit):

byte[] bitValue = BitConverter.GetBytes(1);
connection.SetProperty("PortNameOfLine2",
        StandardDevicePropertyGroups.Source,
        SourcePropertyGroup.PortOutputValue,
        bitValue, null);
connection.SetProperty("PortNameOfLine3",
        StandardDevicePropertyGroups.Source,
        SourcePropertyGroup.PortOutputValue,
        bitValue, null);

daenet wins German innovation prize 2008 for SOA / daenet gewinnt den Innovationspreis 2008 für die Kategorie SOA

Andreas Erben — Thu, 06 Mar 2008 15:41:43 GMT

(German version below / deutsche Version weiter unten)

Now I can finally talk about it. Our daenet SOA Suite now has officially been awarded with an important prize. "http://www.imittelstand.de/auszeichnungen/innovationspreis2008/kategoriesieger/soa.html" The "Innovationspreis 2008" (innovation prize 2008) specifically considers the needs of the so called "Mittelstand". The "Mittelstand" is the engine and the driver of the economy in Germany. Even though it means roughly "medium sized businesses", many of them are international, globalized companies with 10000 employees and more that in the US most often would be called enterprises. What is special about them is the down-to-earth "can-do" attitude and the need for fast return of investment (ROI) coupled with a high level of innovation.

So we are very proud that our SOA solution is being recognized as the BEST SOA solution for the most important customers that possibly could exist for all the right reasons.

The jury was huge and impressive, both academically apt and still with the mindset of delivering value is the key differentiator in life.

Why did we target the needs of the "Mittelstand"? Because we see that a lot of SOA approaches are far too complex for most companies and therefore too much being talked about and too little is being actually done. Being suitable for "Mittelstand" in my opinion automatically means being suitable for enterprises with the advantage that you can "scale" the approach down even to the departmental level.

In future posts I will likely talk more about what the daenet SOA Suite can do... until then: just ask me if you are interested.

(German version / deutsche Version)

Nun kann ich endlich darüber sprechen. Unsere daenet SOA Suite wurde offiziell mit einem wichtigen Preis ausgezeichnet. "http://www.imittelstand.de/auszeichnungen/innovationspreis2008/kategoriesieger/soa.html" Der "Innovationspreis 2008" berücksichtigt besonders die Bedürfnisse des sogenannten "Mittelstand". Der Mittelstand ist der Motor der deutschen Wirtschaft. Auch wenn es eigentlich "Mittelgroße Firmen" bedeutet, sind viele dieser in Wirklichkeit internationale, globalisierte Firmen mit 10000 und mehr Angestellten, die in den USA oft "enterprises" genannt würden. Besonders am Mittelstand ist die Bodenständigkeit und die "wir machen's möglich"-Einstellung, welche aber mit der Notwendigkeit einhergeht, einen schnellen Investitionsrückfluss (ROI) zu erreichen, der mit einem hohen Innovationsbedarf und hoher Innovationskraft gekoppelt ist.

Also sind wir sehr stolz, dass unsere SOA Lösung als die BESTE SOA Lösung für diese Kundenzielgruppe anerkannt wurde, welche sicherlich aus all den richtigen Gründen heraus gesehen die wichtigste Kundenzielgruppe überhaupt ist.

Die Jury selbst war groß und beeindruckend: Akademisch qualifiziert und gleichzeitig mit dem Bewusstsein, dass "Werte schaffen" der Hauptunterscheidungsgrund im Leben ist.

Warum haben wir speziell die Bedürfnisse des "Mittelstand" adressiert? Weil wir sehen, dass viele SOA Ansätze bei weitem zu komplex für die meisten Firmen sind und deshalb zu viel geredet und zu wenig gehandelt wird. Wenn eine Lösung für den Mittelstand geeignet ist, heisst das meiner Meinung nach, dass sie automatisch auch für Konzerne geeignet ist aber den Vorteil mitbringt, nach "unten" skalierbar zu sein, also selbst auf Abteilungsebene einsetzbar zu sein.

In künftigen Artikeln werde ich wahrscheinlich mehr darüber schreiben, was die daenet SOA Suite alles kann... bis dahin: Bitte fragen Sie mich, wenn Sie Interesse haben!

Huge surprise today around daenet and SOA / Heute große Überraschung rund um daenet und SOA

Andreas Erben — Thu, 06 Mar 2008 12:35:18 GMT

(German version below / deutsche Version weiter unten)

Expect a huge surprise today. I am waiting for the official press info to leak out so nobody is upset with me that I talk about it. What I can tell you is that it is around daenet and SOA. It will be one more reason to talk to us when it comes to this topic :)

(German version / deutsche Version)

Heute kommt noch eine große Überraschung auf uns zu. Ich warte noch darauf, dass eine offizielle Presseinfo raussickert, so dass niemand sauer auf mich sein kann, dass ich darüber rede. Was ich jetzt schon sagen kann ist, dass es um daenet und SOA geht. Es wird ein weiterer Grund sein, mit uns über dieses Themengebiet zu sprechen :)

Typical processing of IOPortValueChangedEvents / Typische Verarbeitung von IOPortValueChangedEvents

Andreas Erben — Wed, 27 Feb 2008 11:13:58 GMT

(German version below, deutsche Version weiter unten)

When dealing with IOPortValueChangedEvents, you will have a method like this:

[RfidEventHandlerMethod]
public IOPortValueChangedEvent HandleIOPortValueChangedEvent(
    IOPortValueChangedEvent iOPortEvent)

What to do with it now?
After considering the DeviceName, the PortName, the Source and the Time-properties of the ioPortEvent, usually the most important piece of information is in the byte-array shown here:

byte[] iodata = iOPortEvent.GetPortValue();

(Of course can have VendorSpecificData also, but this special case is neglected here.)

What you want to do for each of these bytes is to be able to compare against it. We look at the "discrete" case where you do not care about continuous values but about specific lines being set somewhere, meaning that specific bits are set to "0" or "1".
This is "old-school". Typically this is done by two things:
1. Define a bitmask with the bits that interest you, use it with "AND" on the retrieved value
2. then compare the result with a value you provide. This gives you pretty good flexibility.
In the case of having only one element in the array above, this is simplified to:

byte ioValue = iodata[0];
ioValue = Convert.ToByte( ioValue & m_InputIOBitMask );
if (ioValue == m_InputIOValue)
{
   // do something
}

(German version, deutsche Version)

Wenn man mit IOPortValueChangedEvents zu tun hat, wird in der Regel eine derartige Methode vorliegen:

[RfidEventHandlerMethod]
public IOPortValueChangedEvent HandleIOPortValueChangedEvent(
    IOPortValueChangedEvent iOPortEvent)

Was nun?
Nachdem man DeviceName, PortName, Source und die Time-Properties von ioPortEvent beachtet hat, ist normalerweise der wirklich relevante Teil in diesem Byte-Array:

byte[] iodata = iOPortEvent.GetPortValue();

(Natürlich kann es auch VendorSpecificData geben, dieser Fall wird hier aber vernachlässigt)

Nun will man in der Lage sein, diese Bytes gegen etwas zu vergleichen. Wir betrachten den "diskreten" Fall, also wo man sich nicht um kontinuierliche Werte kümmert, sondern darum dass bestimmte Verbindungen irgendwo vorhanden sind. Dies bedeutet, dass bestimmte Bits auf "0" oder "1" sind.
Das ist "Old School". Typischerweise wird dies durch zwei Dinge erledigt:
1. Definiere eine BitMask mit den Bits, welche interessant sind und verknüpfe diese mit "UND" mit dem erhaltenen Wert
2. dann wird das Ergebnis mit einem Wert verglichen, für welchen wir uns interessieren. So erreicht man relativ große Flexibilität.
In dem Fall, dass nur ein Element im obigen Array ist, vereinfacht sich dies zu:

byte ioValue = iodata[0];
ioValue = Convert.ToByte( ioValue & m_InputIOBitMask );
if (ioValue == m_InputIOValue)
{
   // irgendwas machen
}

Presentation at the / Präsentation auf den 1st Worldwide Microsoft RFID Solution Days

Andreas Erben — Wed, 20 Feb 2008 03:29:44 GMT

(German version below / deutsche Version weiter unten)

Today I had the honor to present at the 1st Worldwide Microsoft RFID Solution Days (currently the corresponding page can be found here).

You can find my presentation here.

In the presentation I spoke about BizTalk RFID and about how a customer sees potential of real business problems to be solved easily with the help of RFID based technologies, about what the long-term vision is and what components can help building up a sound architecture at the same time.

I introduced the Sensor Service Bus, the daenet SOA Suite and XSYLON and what they can do for a customer.

When talking about the SOA Suite it might have been that some folks might have misunderstood me jokingingly saying that using a virtual distributed service bus with some processing done by the participants instead of the core server might lead to BizTalk selling less licenses. Well, the actual point behind this is, that the patterns introduced by the daenet SOA Suite in fact are different from BizTalk's hub/spoke approach. So, what it actually means is - well, you might sell less BizTalk licenses for the use cases where BizTalk is currently not a good fit anyways. (We are talking about direct communication between clients and services here.)

In the end I have a strong belief in that it is better to deliver customer satisfaction than to sell a product at all cost and have a customer that might end up being unhappy with the solution they get.

So, we are complementing BizTalk with new features and approaches, not competing with it.

(German version / deutsche Version)

Heute hatte ich die Ehre auf den ersten weltweiten Microsoft RFID Solution Days (zur Zeit kann die entsprechende Seite noch hier gefunden werden).

Meine Präsentation ist hier zu finden.

In der Präsentation sprach ich über BizTalk RFID und darüber, wie ein Kunde das Potential sieht, echte Probleme in Geschäftsprozessen mit RFID basierenden Technologien leicht zu lösen, was die langfristige Vision des Kunden ist und welche Komponenten helfen können, das Ganze in einer guten Architektur zu verankern sind.

Ich führte den Sensor Service Bus, die daenet SOA Suite und XSYLON ein und erklärte, was diese Komponenten für einen Kunden tun können.

Als ich über die SOA Suite gesprochen habe, haben mich möglicherweise einige mißverstanden, als ich aus Spaß gesagt habe, dass bei der Verwendung eines virtuellen verteilten Service Bus, wo Teile der Verarbeitung direkt bei den Partizipanten stattfindet, statt auf einem Server im Kern der Verarbeitung,dies dazu führen könnte, dass BizTalk weniger oft verkauft würde. Nun, der Knackpunkt dahinter ist, dass die Patterns, welche über die daenet SOA Suite eingeführt werden tatsächlich unterschiedlich gegenüber dem typischen Hub/Spoke Szenario des BizTalk ist. Was wirklich gemeint ist: Nun, vielleicht verkauft man weniger BizTalk Lizenzen für die Use Cases, wo BizTalk sowieso nicht gut passen würde (denn wir reden hier über die direkte Kommunikation zwischen Clients und Services).

Ich glaube fest daran, dass es besser ist, den Kunden zufrieden zu stellen, als um jeden Preis ein Produkt zu verkaufen und am Ende einen Kunden zu haben, der mit der gelieferten Lösung unglücklich ist.

Wir ergänzen also BizTalk um sinnvolle neue Features und Ansätze und stehen nicht im Wettbewerb damit.

Consideration when using PGL templates to Printronix printers - Was ist bei der Verwendung von PGL Templates für Printronix Drucker zu beachten

Andreas Erben — Wed, 06 Feb 2008 08:28:00 GMT

(German Version below - Deutsche Version weiter unten)

Read the release notes of the Printronix DSPI!

(This section relates to the DSPI available in February 2008)

One relevant part of it says:

The provider does not support locking tags using the Print Wizard. Tags must be locked using the LOCK option in the PGL template.

So, you need to adjust the template when you want to lock tags.

Then:

PGL templates must use DF1 for the Tag Identifier field.
PGL templates must use DF2 for the Tag Data field.
PGL templates must use DF3 for the Access Code field.
PGL templates must use DF4 for the Kill Code field.

For example this means that for BizTalk RFID to "know" what to do when you want to put the Tag Identifier field, you have to put "DF1" in your PGL template.

The SFCC must be ‘~’.

e.g. in the template:

~NORMAL

Do not forget to put "DISK" in your "~CREATE" line

For those who write/edit templates from scratch in PGL or whose tools for editing templates are perhaps flawed, it is important to remember that you need to put "DISK" in your "~CREATE" line.

Example:

~CREATE;RAFU450;216;DISK

If you forget this, then you will try endlessly to send the template to the printer through BizTalk RFID, it will not show up in the list of available templates! Actually BizTalk RFID will send the template just fine, but the printer is missing the instruction to save the template in the flash memory where it needs to be stored, so it will not be available for you.

Vista users (and others): Do not edit the supplied PGL-template examples with Notepad, use a good text editor

"Notepad" of Windows Vista unfortunately does not represent the usual line-feeds correctly (this also applies to some other text editor programs).

Example: RAFU450.pgl in Vista Notepad

Example how it should look like:

~CREATE;RAFU450;216;DISK
RFWTAG;96;EPC
96;DF1;H
STOP
RFWTAG;256;USR
256;DF2;H
STOP
END
~NORMAL

Please use another text-editor that ideally does not do anything fancy like gobbling up those characters or changing encoding or adding prefix bytes...

(German version / deutsche Version)

Die Release Notes des Printronix DSPI lesen!

(Dieser Bereich bezieht sich auf den DSPI, welcher Anfang Februar 2008 verfügbar war.)

Eine relevante Aussage ist:

The provider does not support locking tags using the Print Wizard. Tags must be locked using the LOCK option in the PGL template.

Also muss man im PGL Template vorsehen, dass ein Tag "gelockt" wird.

Dann:

PGL templates must use DF1 for the Tag Identifier field.
PGL templates must use DF2 for the Tag Data field.
PGL templates must use DF3 for the Access Code field.
PGL templates must use DF4 for the Kill Code field.

Dies bedeutet, dass wir die DF1 bis DF4 Felder für die Kern-Tag-Funktionalitäten nutzen müssen, welche BizTalk RFID benötigt. Zum Beispiel benötigt BizTalk RFID das "DF1"-Feld im Template um zu wissen, dass man das Tag Identifier Feld benutzen möchte..

The SFCC must be ‘~’.

Zum Beispiel also im Template:

~NORMAL

Nicht vergessen, "DISK" in der "~CREATE" Zeile anzufügen.

Für diejenigen, welche Templates verändern oder komplett manuell in PGL erzeugen, oder für diejenigen, welche Templates mit Tools verändern, welche vielleicht ein paar Problemchen haben, ein wichtiger Hinweis: In die "~CREATE"-Zeile muss ein "DISK".

Beispiel:

~CREATE;RAFU450;216;DISK

Wenn man dies vergisst, wird man immer wieder erfolglos versuchen, das Template über BizTalk RFID an den Drucker zu übertragen, es wird nie in der Liste der verfügbaren Templates auftauchen. Genauer gesagt macht BizTalk RFID alles richtig, das Template wird ordentlich an den Drucker geschickt, aber es fehlt die Anweisung, dass das Template im Flash Memory, wo es hin muss, abgespeicehrt wird - daher ist es nicht verfügbar.

Bei Problemen also ruhig einmal in einem guten Text Editor (nicht Notepad für Vista, dies stellt Zeilenumbrüche nicht gut dar) im PGL-Template nachschauen.

Vista Benutzer und andere: Die mitgelieferten PGL-Template Beispiele nicht mit Notepad verändern, sondern einen besseren Text Editor verwenden.

Das "Notepad" von Windows Vista stellt leider die üblichen Zeilenumbrüche nicht richtig dar (dies gilt auch für manche anderen Editoren).

Beispiel: RAFU450.pgl in Vista Notepad

Beispiel wie es aussehen sollte:

~CREATE;RAFU450;216;DISK
RFWTAG;96;EPC
96;DF1;H
STOP
RFWTAG;256;USR
256;DF2;H
STOP
END
~NORMAL

Bitte daher einen anderen Texteditor verwenden, der idealerweise keine derartigen Zeichen verschluckt und der auch nicht versucht das Encoding zu verändern oder Prefix-Bytes anzuhängen.

German/deutscher BizTalk RFID Webcast as part of the German/als Teil des deutschen BizTalk Server 2006 R2 Launch

Andreas Erben — Thu, 15 Nov 2007 18:49:00 GMT

(German version below, English version is very minimal since this post is targeted to the German audience)

On November 15, 2007, I presented BizTalk RFID in a webcast format to the German audience in German as part of the launch of BizTalk 2006 R2.

(German version)

Am 15. November 2007 durfte ich BizTalk RFID der deutschen Community im Rahmen des deutschen Microsoft BizTalk Server 2006 R2 Launch-Events vorführen.

Anbei stelle ich gerne allen die Slides hier zum Download zur Verfügung. Für Code-Beispiele und ähnliches möchte ich auf mein vorheriges Blog-Post zur TechEd Developers 2007 in Barcelona verweisen.

Leider war ich durch eine starke Erkältung und damit zusammenhängendem Doping, um den Webcast überhaupt durchführen zu können schwer "gehandicappt" und ich bitte die Teilnehmer um Nachsicht. Gerne spreche ich mit Interessierten im Nachgang über BizTalk RFID.

Der Webcast war leider nur eine Stunde lang und hatte den Anspruch, die technischen Aspekte einem gemischtem Publikum etwas näher zu bringen. Dies ist ein schwieriges Unterfangen, da das Produkt zu umfangreich und die Interessengruppen zu verschieden sind, um es allen recht zu machen. Ich hoffe, dass dennoch ein erstes Gefühl dafür entstand, was man mit Biztalk RFID erreichen kann, über viele Bereiche musste ich leider sehr schnell rüberfliegen und sehr oberflächlich bleiben. Wir wollten dennoch bewusst vermeiden, nur einen Feature-Rundflug mit Marketing-Slides über das Produkt zu machen, sondern zumindest einen kurzen Einblick in das "doing" geben, daher gab es in der Veranstaltung zum Beispiel kurz "Code" zu sehen und auch ein kommendes "SOA-Integrations Pattern", der Sensor Service Bus, wurde kurz vorgestellt.

Nach meiner Meinung wäre es sinnvoll, künftig mehrere Veranstaltungen zum Thema durchzuführen, welche sich beispielsweise wie folgt aufgliedern könnten:

Zielgruppe	Beschreibung
Alle	Allgemeiner Überblick ohne Entwicklung usw – im Gegensatz zu dem „alles in einer Stunde“
Entscheidungsträger/BDMs (Business Decision Maker), Business Analysten, Solution-Architekten	business value: typische Business Szenarien und wie man diese mit BizTalk RFID lösen kann, welchen Business Value BizTalk RFID bietet (z.B. Supply Chain, Asset Management usw.)
Software-Architekten, Entwickler	Architektonische und Integrations Patterns mit BizTalk RFID (vielleicht mit Vertiefung von Sensor Service Bus in gesonderter Session)
Softwareentwickler	Einführung in die synchronen BizTalk RFID APIs
Softwareentwickler	Einführung in die asynchrone BizTalk RFID Entwicklung
Softwareentwickler	Einführung in die DSPI Entwicklung
Architekten, Softwareentwickler	Best Practices, Business Rule Engine, Logging, Performance Aspekte... (lässt sich beliebig ausweiten)
Administratoren, IT-Pros	BizTalk RFID für den IT Pro
Entscheidungsträger/BDMs (Business Decision Maker)	Kundenstories
Alle	Workshops - mit Einbeziehung von Hardware

BizTalk RFID@Work at TechEd EMEA Developers 2007 by daenet

Andreas Erben — Thu, 08 Nov 2007 10:55:30 GMT

(German version below)

Today we presented about Microsoft BizTalk RFID at the TechEd EMEA Developers conference in Barcelona. Some content was similar to the presentation we did last week at the Microsoft SOA&Business Process Management conference in Redmond, but since the audience at TechEd is more developer centric, we prioritized on showing demos and code. You can find our slide deck here: SBP306_Microsoft BizTalk RFID @ Work.zip. This slide deck will also contain additional material not presented in the "Backup slides" section at the end.

Please check out Damir's blog posts to get the bits we talked about:

(German version)

Heute präsentierten wir über Microsoft BizTalk RFID auf der TechEd EMEA Developers Konferenz in Barcelona. Naturgemäß ist einiger Inhalt ähnlich zu dem, was wir letzte Woche auf der Microsoft SOA&Business Process Management conference in Redmond vortrugen. Da die TechEd Developer-fokussiert ist, haben wir den Schwerpunkt auf Demos und Programmierung gesetzt. Das Slide-Deck ist hier verfügbar: SBP306_Microsoft BizTalk RFID @ Work.zip. In der PowerPoint-Datei gibt es zusätzliches Material welches wir leider nicht vorstellen konnten im "Backup slides"-Bereich.

Damir hat in verschiedenen Posts die relevanten vorgestellten Beispiele veröffentlicht.

Presentation at the / Präsentation auf der Microsoft SOA & Business Process Conference 2007

Andreas Erben — Fri, 02 Nov 2007 09:18:00 GMT

(German version below)

Damir and I presented at the Microsoft SOA & Business Process Conference 2007 at the Microsoft Conference Center in Redmond.
We talked about interesting topics surrounding BizTalk RFID, a completely new component of BizTalk 2006 R2, and a new concept named "Sensor Service Bus". It was a relatively technical session, but demonstrates business value in an RTI (Reusable Transport Item) scenario.
If you are interested, we invite you to check out our slide-deck.
We are happy about follow-ups, specifically regarding the "Sensor Service Bus", please do not hesitate to contact us.

(German version / deutsche version)

Damir und ich präsentierten auf der Microsoft SOA & Business Process Conference 2007 im Microsoft Conference Center in Redmond.

Wir stellten interessante Themen rund um BizTalk RFID, eine komplett neue Komponente von Microsoft BizTalk Server 2006 R2, und um das neue Konzept des "Sensor Service Bus" vor. Es handelt sich um eine relativ technische Session, dennoch wird Mehrwert für Kunden in einem RTI (Reusable Transport Items - wiederverwertbare Transportmaterialien) - Szenario demonstriert.
Wir laden interessierte Leser herzlich ein, unser Slide-Deck hierzu anzuschauen.

Wir freuen uns über Folgegespräche, besonders bezogen auf den "Sensor Service Bus". Zögern Sie nicht, uns zu kontaktieren.

Let BizTalk RFID handle your EventHandler-component logging / Lassen Sie BizTalk RFID das Logging für Ihre EventHandler-Komponenten übernehmen.

Andreas Erben — Wed, 31 Oct 2007 10:59:51 GMT

German version below

The Visual Studio project template for BizTalk RFID EventHandlers that is shipped with BizTalk RFID demonstrates nicely, how you should use logging from your EventHandler-components unless you have a really good reason to do otherwise :)

You can use the static method RfidProcessContext.GetLogger to retrieve the logger. Furthermore you can retrieve context specific information about the logger through the RfidProcessContext instance that you receive in the "Init"-Method of your EventHandler component.

The logger exposes quite some methods to log. The most natural to use is "Log" as shown below.

internal void InitializeLog(RfidProcessContext container)
{
    if (myLogger != null)
        return;
    string loggerName = this.GetType().Name;
    myLogger = RfidProcessContext.GetLogger(loggerName);
    //inherit log level from the process
    myLogger.CurrentLevel = RfidProcessContext.GetLogger(container.ProcessName).CurrentLevel;
    myLogger.Info("starting logging for {0}", loggerName);
}
 
internal void LogMessage(string msg, Level msglevel)
{
    myLogger.Log(msg, msglevel);
}

German version:

The Visual Studio Projekt Template für BizTalk RFID EventHandlers, welches mit BizTalk RFID mitgeliefert wird, zeigt nett, wie man innerhalb eigener EventHandler-Komponenten Logging nutzen sollte, sofern man nicht einen wirklich guten Grund hat, einen anderen Ansatz zu wählen :)

Über die statische Methode RfidProcessContext.GetLogger erhält man den Logger. In der "Init"-Methode der EventHandler-Komponente erhält man ferner eine RfidProcessContext Instanz, welche man verwenden kann, um kontextspezifische Informationen über den Logger zu erhalten.

Der Logger stellt eine stattliche Anzahl von Methoden für Loggingzwecke zur Verfügung, die naheliegendste ist die Methode "Log", wie oben gezeigt.

Refresh your BizTalk RFID documentation! Holen Sie sich die neue BizTalk RFID Dokumentation!

Andreas Erben — Fri, 26 Oct 2007 01:25:44 GMT

(German version below)

As with a recent customer scenario we were wondering what the customer was talking about: Please remember that BizTalk RFID documentation was updated after the launch. You can download it here:

http://www.microsoft.com/downloads/details.aspx?FamilyID=22b2e8d9-8cda-44f8-8f4e-b372c7660989&DisplayLang=en

German version:

In einem Kundenszenario wunderten wir uns, über was unser Kunde spricht. Daher möchten wir hier darauf aufmerksam machen, dass die BizTalk RFID Dokumentation kurz NACH dem Launch aktualisiert wurde. Sie können diese hier runterladen:

http://www.microsoft.com/downloads/details.aspx?FamilyID=22b2e8d9-8cda-44f8-8f4e-b372c7660989&DisplayLang=de

BizTalk Rfid EventHandler recap

Andreas Erben — Mon, 08 Oct 2007 01:12:27 GMT

(German version below)

For those who are new to BizTalk RFID or have not used it in a while, here is a recap of the minimal requirements for implementing a EventHandler component.

Inherit from RfidEventHandlerBase
Parameterless constructor must be accessible
Implement public static method RfidEventHandlerMetadata
Override method Init
Mark at least one method with attribute [RfidEventHandlerMethod] with signature:

Accepting one parameter of type RfidEventBase or RfidEventBase[] (or derived from those)
Returning RfidEventBase or RfidEventBase[] (or derived from those) or void
Return-type void specifies an EventSink
Typical EventHandler will use type TagReadEvent and TagListEvent

A minimal EventHandler would look like this:

using System;
using System.Text;
using System.Collections.Generic;
using Microsoft.SensorServices.Rfid;
using Microsoft.SensorServices.Rfid.Utilities;
 
namespace MinimalEventHandler
{
    public class MyEventHandler : RfidEventHandlerBase
    {
        public static RfidEventHandlerMetadata GetEventHandlerMetadata(bool vendorextensionalso)
        {
            return null;
        }
 
        public override void Init(Dictionary<String, object> parameters, RfidProcessContext container)
        {
        }
 
        [RfidEventHandlerMethod]
        public RfidEventBase MyEventHandlerMethod(
            RfidEventBase myEvent)
        {
            return myEvent;
        }
    }
}

Alternatively "MyEventHandlerMethod" could look like this:

public RfidEventBase MyEventHandlerMethod(RfidEventBase[] myEvent)

public RfidEventBase[] MyEventHandlerMethod(RfidEventBase myEvent)

public RfidEventBase[] MyEventHandlerMethod(RfidEventBase[] myEvent)

or in case you would want to create an EventSink

public void MyEventHandlerMethod(RfidEventBase myEvent)

public void MyEventHandlerMethod(RfidEventBase[] myEvent)

In a "real life" scenario you typically would choose TagReadEvent and TagListEvent instead of RfidEventBase.

German version:

Für Einsteiger in BizTalk RFID oder Kollegen, welche BizTalk RFID längere Zeit nicht nutzten, hier eine kurze Zusammenfassung der Minimalanforderungen, welche eine EventHandler-Komponente zu erfüllen hat.

Von RfidEventHandlerBase ableiten
Parameterloser constructor must erreichbar sein
Die public-statische Methode method RfidEventHandlerMetadata muss implementiert werden
Überschreiben (Override) der Init-Methode
Mindestens eine Methode muss mit dem Attribut [RfidEventHandlerMethod] markiert werde und folgende Signatur haben:

Akzeptieren eines Parameters des Typs RfidEventBase oder RfidEventBase[] (oder ein hiervon abgeleiteter Typ)
Zurückgeben von RfidEventBase oder RfidEventBase[] (oder ein hiervon abgeleiteter Typ) oder void
Rückgabe-Typ void spezifiziert, dass ein EventSink vorliegt.
Ein typischer EventHandler verwendet die Typen TagReadEvent und TagListEvent

Ein minimaler EventHandler würde folgendermassen Aussehen:

using System;
using System.Text;
using System.Collections.Generic;
using Microsoft.SensorServices.Rfid;
using Microsoft.SensorServices.Rfid.Utilities;
 
namespace MinimalEventHandler
{
    public class MyEventHandler : RfidEventHandlerBase
    {
        public static RfidEventHandlerMetadata GetEventHandlerMetadata(bool vendorextensionalso)
        {
            return null;
        }
 
        public override void Init(Dictionary<String, object> parameters, RfidProcessContext container)
        {
        }
 
        [RfidEventHandlerMethod]
        public RfidEventBase MyEventHandlerMethod(
            RfidEventBase myEvent)
        {
            return myEvent;
        }
    }
}

Alternativ könnte "MyEventHandlerMethod" so aussehen:

public RfidEventBase MyEventHandlerMethod(RfidEventBase[] myEvent)

oder

public RfidEventBase[] MyEventHandlerMethod(RfidEventBase myEvent)

oder

public RfidEventBase[] MyEventHandlerMethod(RfidEventBase[] myEvent)

oder im Falle man einen EventSink erzeugen möchte:

public void MyEventHandlerMethod(RfidEventBase myEvent)

oder

public void MyEventHandlerMethod(RfidEventBase[] myEvent)

In einem realen Szenario würde man typischerweise TagReadEvent und TagListEvent anstatt RfidEventBase wählen.

BizTalk RFID integration too slow? BizTalk RFID Integration zu langsam?

Andreas Erben — Wed, 30 May 2007 20:40:53 GMT

(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.

Erster Blick auf Microsoft BizTalk RFID

Andreas Erben — Mon, 09 Apr 2007 14:27:00 GMT

This blog-post is based on the English-language post "First look at Microsoft BizTalk RFID" found in the blog of Damir Dobric. There is no new information in the German language version.
Dieser Blog-Post basiert auf dem englischsprachigen Post "First look at Microsoft BizTalk RFID" aus dem Blog von Damir Dobric. Er enthält keine grundsätzlich neue Aussagen oder Informationen gegenüber der englischsprachigen Version.

Microsoft BizTalk RFID ist eine offene Plattform, welche es Herstellern möglich macht, auf Microsoft Technologien basierende RFID Lösungen zu entwickeln. Im Kern ist es ein Satz von APIs, welche auf dem .NET Framework 2.0 aufsetzen, die es erlauben, Anwendungen durch sogenannte Eventhandler zu erstellen. Generell bietet das Microsoft RFID Services Framework einen recht mächtigen Funktionssatz in folgenden Bereichen an:

Synchrone Kommunikation mit Endgeräten (devices)
Asynchrone Eventverarbeitung
Management Funktionalitäten

API und Befehlsmodell (Command Model)

Das synchrone Befehlsmodel ist dadurch gekennzeichnet, dass ein Aufrufer einen Aufruf (Request) über BizTalk RFID Services Framework an ein RFID-Endgerät (device) schickt und solange wartet, bis er eine Antwort durch den RFID service erhält. model is when the caller issues a request to BizTalk RFID Services Framework
and waits until it receives a response from the RFID service. Ein solches Endgerät kann beispielsweise ein RFID Reader (RFID-Lesegerät) oder ein RFID Printer (RFID Drucker) sein. Mit RFID Drucker können Labels, also Etiketten mit RFID-Tag, bedrucken und den RFID-Tag gegebenenfalls mit spezifischen Daten füllen.

Im asynchronen Befehlsmodell schicken RFID Geräte Benachrichtigungen an das BizTalk RFID Services Framework, welches dann dies als Ereignisse (Events) verarbeitet und an passende RFID Prozess-Pipelines weiterleitet. Dies ist das am häufigsten verwendete Muster, welches man in RFID-Anwendungen, die auf dieser Plattform basieren, finden wird.

Das Management Befehlsmodell beinhaltete administrative Ereignisse, z. B. über das Versagen von spezifischen Endgeräten oder über den Ausfall der Stromversorgung der Endgeräte, oder wenn ein Prozess gestoppt wird.

Abbildung von Prozessen Dealing with Processes

Das RFID services Framework ist im Namespace "Microsoft.SensorServices.RFID" implementiert, welches au seiner reihe von managed (.NET 2.0) Assemblies besteht. Das Framework selbst läuft in einem Windows-Service namens BizTalkRfid, der im Prozess RfidServices.exe gehostet wird.

RFID Dienste werden in durch die durch die unten abgebildete RFID Management Konsole verwaltet:

Alle Einstellungen, welche in dieser Konsole getroffen werden können, sind in einer Datenbank gespeichert. Diese Datenbank heißt per Default "RFIDSTORE". Die Management Konsole steuert RFID relevante Geschäftsprozesse. Im oberen Bild sind drei Geschäftsprozesse aufgeführt: ScannenEingang, TestProcess and xasd.

Wenn man mit RFID Diensten zu tun hat, gibt es einige wichtige Entitäten, welche im folgenden erklärt werden:

Device (Endgerät)
Die erste wichtige Entität ist das RFID Device, also das physische Endgerät. Dies kann zum Beispiel ein RFID-Reader sein. Um dieses Gerät zu nutzen, muss ein Provider für das Gerät installiert sein. Dieser RFID Device Provider ist ein gemanagter Treiber und implementiert die gerätespezifische Kommunikation ab. Durch ihn werden Device Management, sowie das Lesen oder Schreiben von Daten in allen drei genannten Befehlsmodellen abgebildet. Die Architektur des Frameworks erlaubt übrigens, auch Provider zu implementieren, welche nicht nur mit RFID Geräten umgehen, sondern mit beliebigen Arten von Sensoren. Die Plattform bietet nach unserer Meinung viel mehr, als nur RFID spezifische Funktionalitäten. Der Namespace der Assembly "Microsoft.SensorServices.RFID" deutet ebenfalls in die Richtung, dass man weiter denkt, als nur RFID-spezifische Funktionalitäten auf dieser Infrastruktur aufzusetzen. Wir experimentierten bereits mit verschiedenen anderen Datenquellen wie Ultraschalldaten, File IO-Ereignissen usw. Wenn man in der Lage ist, einen passenden funktionierenden Provider zu erstellen, gibt es keine technische Limitierung, irgendeine andere Art von "Sensorik" in das Framework einzubinden. Es gibt noch eine Unterscheidung zwischen logischen und physischen Devices, auf welche hier aber nicht eingegangen wird.

Component (Komponente)
Eine Komponente ist eine .NET Assembly, welches ein spezifisches Interface implementiert und in einer Kette von Eventhandlern installiert wird. Die vom Gerät gelesenen Daten werden asynchron zum ersten Eventhandler geschickt. Nach der Verarbeitung kann der Eventhandler die Daten unverändert oder manipuliert an den nächsten Eventhandler in der Kette weitersenden. Der letzte Eventhandler im Stack ist die sogenannte Eventsenke (Event Sink). BizTalk RFID wird mit einer SQL-Eventsenke ausgeliefert, welche die empfangenen Daten in einer SQL Server Datenbank speichert.

Process (Prozess)
Jeder Businessprozess ist eine logische Entität, welche eine Menge von Geräten (devices) oder Device-Gruppen mit einem Satz von Komponenten verbindet. Nehmen wir zum Beispiel an, dass es zwei Geräte D1 und D2 gibt, welche als Gruppe G1 zusammengefasst sind und nehmen wir an, dass es zwei Komponenten (Eventhandler) EH1 und EH2 gibt. Der erste Handler EH1 könnte verwendet werden, um Dubletten herauszufiltern und der zweite Handler EH2 könnte die SQL-Eventsenke sein, welche einfach Daten in die Datenbank schreibt. Man kann nun einen Prozess P1 definieren, welcher die Device-Gruppe G1 mit den Komponenten (Eventhandlern) EH1 und EH2 verbindet. Zur Veranschaulichung: Der Prozess P1 ist ein Geschäftsprozess welcher Daten von den Readern liest, welche sich hinter den Devices D1 und D2 verbergen, dann zuerst die doppelten, redundanten Tag-Leseereignisse ausfiltert und diese zur späteren Auswertung in eine Datenbank schreibt.

Das ist in Kürze die Kernidee, welche hinter der RFID Services Plattform steckt.

Wir hören oft die Frage: Was hat die Microsoft RFID Services Plattform mit BizTalk Server zu tun?

Die Antwort ist zweigeteilt:
Technisch gesehen derzeit nichts. Aus einer Marketing und Produktsicht kann es aber Sinn machen, dies zusammenzubundeln, was in diesem Post nicht weiter diskutiert wird.
Aber man darf in diesem Kontext nicht vergessen, dass BizTalk RFID auf einem technisch sehr aktuellem Stand ist, während die BizTalk Server Engine und Infrastruktur eine seit mehreren Jahren gewachsene Struktur darstellt. Eine stärkere "technische" Integration hätte entweder erfordert, große Teile des BizTalk Server umzubauen, oder hätte möglicherweise dazu geführt, dass BizTalk RFID nicht konsequent auf einem technisch aktuellem Framework (.NET 2.0) aufsetzen kann. Es gibt, wie wir in späteren Posts sehen werden, Möglichkeiten, die Integration mit dem "Rest" des Produktes BizTalk Server mit relativ geringem Aufwand stattfinden zu lassen.

Wir hoffen, dass dieses Post hilft, die (hier stark vereinfachten) Grundlagen der Microsoft RFID Plattform zu verstehen.