Search results matching tags 'BizTalk Server 2006', 'BizTalk', and 'BizTalk RFID'

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

aerben — 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

aerben — 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

aerben — 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

aerben — 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

aerben — 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

aerben — 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

aerben — 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

aerben — 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

aerben — 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

aerben — 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.