CHEP will use BizTalk 2006 R2 (RFID) Globally ;-)

CHEP chooses Cactus Commerce to develop
Global Track & Trace RFID Solution


Microsoft Gold Certified RFID systems integrator helps leading logistics company extend the benefits of RFID to their customer


OTTAWA, ON and LOS ANGELES, CA – October 16, 2006 – Cactus Commerce Inc., a leading provider of software and services for e-business, today announced that it has been chosen by CHEPT to develop the first commercial application of an RFID solution for product AND asset tracking that extends the business benefits of RFID to customers worldwide, including those in the automotive, consumer packaged goods and retail industries.


CHEP, the global leader in pallet and container pooling services serving many of the world’s largest companies, wanted to provide real time visibility to its customers for their products as well as the CHEP’s reusable assets in the extended supply chain. The read data generated across different read points will be transformed into series of actionable reports that will benefit the customer’s bottom line.


“Our focus is on enabling visibility across all the touch points in the supply chain,” says Puneet Sawhney, Global Program Manager, RFID, CHEP, “We wanted to use a solution that is scalable, easily deployable, standards-based and offers lowest total cost of ownership. We also wanted to ensure that the front end for data capture and reporting was user-friendly and provided easy customization to meet the needs of our different businesses around the world.”


To help CHEP achieve this goal, Cactus Commerce is building CHEP’s track and trace solution on top of the Microsoft BizTalk RFID platform, which will be part of BizTalk Server 2006 R2, to manage the RFID equipment and transactions, and enable data capture, reporting and integration to help feed cumulative detail to CHEP’s ERP system, which offers analytics, reporting and tracking functionality.


“Cactus’ solution takes advantage of the RFID capabilities in Microsoft BizTalk Server 2006 R2 to offer broad compatibility between backend systems and hardware systems alike,” says Jean-Yves Martineau, CTO and Co-Founder of Cactus Commerce, “Cactus and Microsoft offer a single, unified RFID solution, which is critical in promoting supply chain efficiency on a global scale.”


“Customers have a growing need for better connectivity across their supply chain in order to drive efficiency and obtain a real-time view of their processes,” said Burley Kawasaki, group product manager for BizTalk Server at Microsoft Corp. “We are pleased to work with Cactus Commerce to help customers reduce complexity associated with the management of intelligent RFID hardware, and gain increased agility through BizTalk’s RFID functionality.”


Cactus Commerce delivers solutions for the retail, manufacturing and logistics industries as part of the Microsoft Smarter Retailing initiative, a framework designed to improve customer service and selling opportunities through solutions that can more easily provide a single, consolidated view of customer and product information whenever and wherever it is needed. This includes software tools that empower people to drive enhanced supply chain efficiency and trading partner collaboration, and easily manage the adoption of transforming technologies such as Global Data Synchronization and RFID.


Cactus Commerce and Microsoft Corporation will be on stage with CHEP at the EPCglobal U.S. Conference in Los Angeles, CA for an Interactive Workshop Session on Thursday, October 19 from 8:30 AM – 10:00 AM, that will discuss this Global Track and Trace solution. The session, C2: Asset Management: The ROI of Asset & Product Tracking, will teach attendees how to identify ROI through examining individual business areas that can reduce costs through an EPC/RFID infrastructure.


About Cactus Commerce
Cactus Commerce is an e-business software and services company with over 10 years of experience integrating Microsoft solutions. Cactus Commerce is a founding member of the Microsoft RFID Partner Advisory Council (PAC) and an active member of EPCglobal. Experienced in delivering vertical solutions, Cactus is actively working with large Retailers, Manufacturers and Logistics companies such as CHEP to utilize RFID event data in critical business processes and systems in order to accelerate business decisions and provide new insights to all levels within the supply chain. Cactus solutions for e-Commerce, Enterprise Collaboration & Integration and Supply Chain Management enable companies to collaborate electronically with business partners, taking full advantage of their existing and future Microsoft technology investments. For more information, please visit
www.cactuscommerce.com .


The names of actual companies and products mentioned herein may be the trademarks of their respective owners.

EDI Processing Modes in BTS2006 R2

Today we will discuss EDI processing options supported on the Receive Side.


EDI Receive Side enables BizTalk to ‘receive’ and process EDI encoded documents. R2 delivers a EDI Receive Pipeline which includes DASM to parse and validate the interchange and also generate appropriate Acknowledgements (e.g., TA1, 997 or CONTRL)


The EDI Receive Pipeline supports three processing modes and the selections are enabled at Party Level via controls in Party/EDI Properties on the BizTalk Server 2006 Admin Console, the three options are listed below. 



  • Generate Transaction Set XML, Aka De-batching: This is the traditional processing model wherein the incoming Interchange/Group is split into individual Transaction Set XML and generates ’multiple’ Transaction Set XML per Interchange – one for each ’valid’ Transaction Set.

  • Generate Interchange XML – Suspend Interchange on Error: One Interchange XML is generated for the entire incoming EDI Interchange. On encountering error the Interchange is suspended. In this processing mode the interchange structure is always preserved.

  • Preserve Interchange XML – Suspend Transaction Set on Error:  One Interchange XML is generated for the entire incoming EDI Interchange. On encountering error the erroneous Transaction Set is suspended. In this processing mode the interchange structure may not be preserved.

The flow diagram in Figure 1 (also available as attachment with the blog) along with the verbiage elaborates on the processing options.


 


 


 


The Figure is a flow diagram illustrating processes for configuring translation of EDI Interchange files to XML representation(s).



  • At 100, a user may configure, the way to translate incoming Interchange files.

  • At 110, a user may decide whether to generate a single XML representation for the entire Interchange file received, or to generate multiple XML representations, one for each Transaction Set of the Interchange.

  • If the option to Split Interchange is selected, then configuration option 120 is enabled, i.e., one XML file is generated for each Transaction Set, minus any Transaction Sets with errors.

  • At 130, user option will produce a single representation can be advantageous when order of the transaction sets is important. For instance, where breaking up the Interchange into individual XML representations for each Transaction Set would lose the ordering of the Transaction Sets, it may be beneficial to translate the interchange to a single XML representation that maintains the structure of the EDI Interchange. If this option to Preserve Interchange is selected (130), then a user may additionally choose to configure how to handle errors.


    • For instance, if a user chooses to suspend messages with errors via configuration option 140, then one XML representation is generated for the Interchange while dropping any Transaction Sets with errors.

    • Option 150 in turn avails the user the option to configure the system to produce no XML if any of the Transaction Sets of the Interchange are invalid, or include bad data. Option 250 might be appropriate where all transaction sets are critical, or lose information when separated.

In summary, the Receive Side thus provides the ability to preserve an ’entire’ Interchange per the incoming sequence, the ability to drop erroneous transaction sets and regenerate the interchange while updating footer totals and the ability to control this behavior via configuration options in the Trading Partner Manager Console.


 

Modifying the MSH Schema for additional sub-elements

In responding to thispost, I did a test and found out a something that I did not realize:

You need to follow the EXACT naming standard in element declaration. I modified the schema to look like this:

<xs:element minOccurs=”1” maxOccurs=”1” name=”MSH.10_MessageControlId“>

<xs:complexType>

<xs:sequence>

<xs:element minOccurs=”1” maxOccurs=”1” name=”CM_MSG.0_MessageControlId” type=”ST” />

<xs:element minOccurs=”0” maxOccurs=”1” name=”CM_MSG.1_X” type=”ST” />

</xs:sequence>

</xs:complexType>

</xs:element>

I modified the sample message to look like this:

MSH|^~\&|IE|MCM|BTAHL7InterfaceEngine||199601121005||ADT^A03|000001^1|P|2.3.1

And the resulting xml looks like this:

<ns0:MSH_24_GLO_DEF xmlns:ns0=”http://microsoft.com/HealthCare/HL7/2X”>

<MSH>

<MSH.2_EncodingCharacters>^~\&amp;</MSH.2_EncodingCharacters>

<MSH.3_SendingApplication><HD.0_NamespaceId>IE</HD.0_NamespaceId></MSH.3_SendingApplication>

<MSH.4_SendingFacility><HD.0_NamespaceId>MCM</HD.0_NamespaceId></MSH.4_SendingFacility>

<MSH.5_ReceivingApplication>

<HD.0_NamespaceId>BTAHL7InterfaceEngine</HD.0_NamespaceId>

</MSH.5_ReceivingApplication>

<MSH.6_ReceivingFacility>

<HD.0_NamespaceId></HD.0_NamespaceId>

</MSH.6_ReceivingFacility>

<MSH.7_DateTimeOfMessage>

<TS.1>199601121005</TS.1>

</MSH.7_DateTimeOfMessage>

<MSH.8_Security></MSH.8_Security>

<MSH.9_MessageType>

<CM_MSG.0_MessageType>ADT</CM_MSG.0_MessageType>

<CM_MSG.1_TriggerEvent>A03</CM_MSG.1_TriggerEvent>

</MSH.9_MessageType>

<MSH.10_MessageControlId>

<CM_MSG.0_MessageControlId>000001</CM_MSG.0_MessageControlId>

<CM_MSG.1_X>1</CM_MSG.1_X>

</MSH.10_MessageControlId>

<MSH.11_ProcessingId>

<PT.0_ProcessingId>P</PT.0_ProcessingId>

</MSH.11_ProcessingId>

<MSH.12_VersionId>

<VID.0_VersionId>2.3.1</VID.0_VersionId>

</MSH.12_VersionId>

</MSH>

</ns0:MSH_24_GLO_DEF>

Virtual Server has missing Virtual Machines after reboot

After rebooting my machine, I could never get the machines to show up again, always stating that

The configuration file (C:\Documents and Settings\NetworkService\My
Documents\SQL\Reporting Services.vmc) referenced by the configuration link
“C:\Documents and Settings\All Users\Application Data\Microsoft\Virtual
Server\Virtual Machines\Reporting Services.lnk” could not be found.

I would then have to go in and delete the file “C:\Documents and Settings\All Users\Application Data\Microsoft\Virtual
Server\Virtual Machines\Reporting Services.lnk” and reassociate the machine.

I resolved this problem by putting the machines in the default folder (defined in the Default Paths in the Virtual Server configuration page) instead of my personal folder in ‘My Documents’

BizTalk: Business Rule Engine: Don’t use vocabulary in development

BizTalk: Business Rule Engine:
Don’t use vocabulary in development!

 

Why?

 

Because it gives you big headache and so little instead of.

 

Our typical work with the facts in the rules is compounded from the steps:

 

* Changing/Add fact in/to a rule (if fact is in the one of the tabs of Fact Explorer): Without vocabulary we change/add fact in a rule by drag-and-drop it from the Fact Explorer. With vocabulary we drag-and-drop a definition from the Fact Explorer. No difference.

 

* Changing/Add fact in/to a rule (if this fact is not in vocabulary):
Without vocabulary we work as before. With vocabulary we create a new version of our vocabulary (we can not change the old version because it is published (we have to publish the vocabulary otherwise we can not use its facts in the rules)).

 

* Cut the old version of the vocabulary:
In the rules we change all facts from the old version to the facts from the new version. If we have some facts in vocabulary with reference to it from some rule we can not delete the old version of vocabulary with this fact. (I know the free utility for this purpose but don’t recommend it because I had the unpredictable behaviour of the rules after such automatic updates of the facts.)
In the real work it looks like: OK. This rule is near finish. I create a rule set but it use several versions of the one vocabulary and I don’t like it. I want to cut the old versions. (I don’t like to deploy many versions of one vocabulary. It creates absolutely mess.) I have to manualy upgrade the facts, change old version to a new one, then delete old versions of the vocabulary. But… the vocabulary is “near” finish. Oops, I need change one more fact inside (and create one more version). It’s always “near”…
When I work with the rule I can cange and it, change it without creating a new rule version. But with vocabulary it is completely prohibited. I can use vocabulary and test it only after publishing (“freeze and use”).
OK. I’m trying to separate one vocabulary to two. One is the “Stable”, the second is “Mutable”. It can make my life easy. Wow, how interesting. I was thinking the vocabulary helps me to keep in mind less entities, but now I have to create an additional infrastucture…
BTW I don’t understand why we can’t freeze the vocabulary with policy together.

 

One more time.
A new fact: Without vocabulary I drag-drop new fact to the rule.
With vocabulary I have to:
1. create a new version of the vocabulary.
2. add a new fact to it. And it is NOT short way! I do not describe here the odds of this step.
3. Save and Publish (and, maybe, Deploy) new version.
4. drag-drop new fact from vocabulary.

 

Additional work:
1. creating a definition in the vocabulary.
2. changing the old definition in the rules on the new definition from the last version of vocabulary.
3. managing versions of the vocabulary.
4. in deployment: creating, deploying and managing the vocabulary.

 

Pro for Vocabularies:
* short names of facts in the rules. But in the rules we do not see “very long names” (not like “xpath-names” in maps: “/*[local-name()=’EDI’ and namespace-uri()=’http://VPA.EDI.Schemas.EDICanonical’]/*[local-name()=’VesselID’ and namespace-uri()=”]”), we see readable names as “VPA.EDI.Schemas.EDICanonical:EDI/VesselID”. It is very “small pro”.
* readable names and formats for the facts. It is a good Pro for the end users.

 

Conclusion: I can see only one case when a vocabulary worth all this additional headache: If we have very stable rule set in the production and we can give it to the end power users (BTW never seen this mythic user).
In the real development never

Alternative Rete implementations

For the other two people in the world who are interested in such things, Peter Lin, Chimezie Ogbuji, Johan Lindberg and I have been debating the finer points of Rete engine implementation over on Peter's web site.   The main thing to emerge from this was a much clearer understanding of the alternative approaches that can be taken when implementing Rete networks (I told you there would only be a couple of people interested in this!).   Chimezie is the author of a reasoning system called FuXi (pronounced 'foo-see', please) which extends a Python-based engine called Pychinko.   Pychinko and FuXi are designed to apply rules to RDF triplets, and therefore can be applied to the semantic web.   With good reason, they use a rather different implementation for the alpha part of their Retes than the approach used in most engines. 

All a little obscure, I realise, for my normal readers, but someone may be interested.

The debate can be found at:

Difference between RETE/UL and Forgy RETE
http://woolfel.blogspot.com/2006/10/difference-between-reteul-and-forgy.html

For me, the debate began earlier at:

Wikipedia has been updated
http://woolfel.blogspot.com/2006/10/wikipedia-has-been-updated.html

Previously posted at http://blog.solidsoft.com/blogs/charles_young_mvp_biztalk/default.aspx