none
Export Model - Strict

    Question

  • Hi,

    Can anyone explain the use of "Export Model" (strict or default) in Itineraries.  I have tried to put together an Itinerary that uses a Broker Service and Broker Outports with filters based on context properties.  When you try and export the model it insists that "Export Model" be set to strict.  I havent found much doco or any samples. 

    After exporting the model to file I can see that additional attributes get created for the export model strict -> stage | id | nextid | businessname.

    I get routing failures when using the Export Model strict.


    MSDN doco:

    When creating BizTalk ESB Toolkit itineraries using the Itinerary Designer, the Export Mode property can be used to define where the service will execute. Setting the Export Mode property to Strict ensures that the itinerary service executes in its prescribed container; in this case, each itinerary service in the XML itinerary has a stage property that specifies the pipeline in which the service executes. If this property is set to Default, an itinerary compatible with Microsoft ESB 1.0 is created, with no stage specified, and the itinerary service executes in the order prescribed, but not necessarily in the pipeline stage desired.

    Tuesday, July 14, 2009 3:45 AM

Answers

  • The strict mode requires a routing step before the Off-Ramp extender.  This is because the stage is honored (Off-Ramp stage is OffRamp SendTransmit) and also the Off-Ramp extender purpose is to set up subscriptions for the Off-Ramp to work.  The routing step is responsible for setting up transport and location information.  The Off-Ramp extender with resolver was included to support V1 itineraries.

    Thanks,


    Brendon Birdoes, Neudesic
    Wednesday, July 15, 2009 6:13 AM
    Moderator

All replies

  • The strict mode supports new features such as stage and the broker.  As mentioned in the docs the stage attribute is output and utilized by the ESB Dispatcher in On-Ramps and Off-Ramps.  Without it, the engine basically processes as many steps as it can until it ends or hits an orchestration or off-ramp step.  With the stage attribute the engine can skip a step and not execute it until the correct pipeline direction.  For example, if you want a transform to run on a request-response (service pass-through) scenario on the Off-Ramp's receive pipeline, the only way to do this is to have the stage attribute.  This could be a common scenario since the original requestor may not expect the message in the format returned by the service.  In default mode the transform would always execute on the Off-Ramp's send pipeline.

    The broker capability utilizes the id and next id to work correctly.  In V1 the steps are processed sequentially.  For more advanced routing like the broker the engine needed a way to jump to steps.  The pattern was basically to use a linked list within the itinerary.  The outcome of these filters really is to determine the correct id to jump to for the next step.

    Simply put, Default mode is for backward compatibility with V1 itineraries.  Strict mode is required for many of the new V2 features.  For itineraries that I build I generally use Strict mode.

    Have you resolved the routing failures?


    Brendon Birdoes, Neudesic
    Tuesday, July 14, 2009 4:45 AM
    Moderator
  • Thanks for the explanation Brendan.  Sorry for the delay in response.

    I still have the routing issue.  Originally I was trying to use a Broker Service within my itinerary but have stripped it back to just:

    1) On Ramp
    2) Off Ramp Extender (resolver static file location)
    3) Off Ramp

    I have the dynamic send port filters set (servicetype | servicename | servicestate), and receive location pipeline (ItinerarySelectReceiveXml) ITINERARY-STATIC

    The itinerary works fine under the default export model, yet I get routing issues (no subscribers found) when using strict export model.

    Wednesday, July 15, 2009 4:56 AM
  • The strict mode requires a routing step before the Off-Ramp extender.  This is because the stage is honored (Off-Ramp stage is OffRamp SendTransmit) and also the Off-Ramp extender purpose is to set up subscriptions for the Off-Ramp to work.  The routing step is responsible for setting up transport and location information.  The Off-Ramp extender with resolver was included to support V1 itineraries.

    Thanks,


    Brendon Birdoes, Neudesic
    Wednesday, July 15, 2009 6:13 AM
    Moderator