Itinerary Cache issue

Sep 16, 2010 at 9:13 PM
Edited Sep 16, 2010 at 9:21 PM


I am using this resolver successfully. However, for example if using this on a ws-BasicHttp receive location (two-way) when I submit a message and use the promoted properties to evaluate a BRE rule it works OK - i.e., selects the correct itinerary. When I change the message (and hence the promoted context value) it seems to always select the itinerary from the first message - ie from when the BRE rule was first run. If I recycle IIS then it works ok but I have to do this every time I change the message and hence a promoted property.

Similarly if I use a File Receive Location (therefore one-way) I have to recycle the BTS instance every time I change the message also.

I am not sure if it is a problem with the Tellago resolver or I have to do something in the BRE when creating the Policy.

I have changed the esb.config and the cache time out value from 120 to 0 and 1 with no luck, in fact I have changed all the cache timeouts to 0 and 1 with no luck. I have also changed he IntineraySend Itinerary cache from 3600 to 0 (one-way) as well as the ForwarderItinerarySend on the receive pipeline (for the two-way) scenario. Although as I understand it the Itinerary Cache is only applicable to two-way receive ports not a one-way so not sure why its happening in the File Receive scenario.

in both cases (one-way and two-way) I am using a custom receive pipeline with  a custom debatcher in the dissasember stage and the ESBSelector and ESBDispatcher in the Resolve Party stage. in the custom dissasember I am using the getNext() method promoting a property (to be used in the rule) i.e., https://WCFCRUD.ESBDBPropertySchema#Action

This is the connection string I am using BRE.EXT:\\policy=MTNItinerarySelection;version=1.13;useMsg=True;useMsgCtxt=True;msgCtxtValues=https://WCFCRUD.ESBDBPropertySchema#Action.

My policy has 2 rules

Rule1 - if MessageType=namespace#root and https://WCFCRUD.ESBDBPropertySchema#Action=ADD then select Itinerary A

Rule2 - if MessageType=namespace#root and https://WCFCRUD.ESBDBPropertySchema#Action=SELECT then select Itinerary B

Dropping the Envelope Message the first time with a promoted Action property of SELECT for example executes Rule2 succesfully and Itinerary B is followed. However changing the promoted Action property from SELECT to ADD for example will always return Itinerary B and not A. Somehow the First Rule is cached and always run no matter what message/context property is set. restarting iis (two-way) or the instance host between messages is the only way it runs the correct rule. To be honest I am not sure if its the rule thats cached or the Itnerary....


Sep 17, 2010 at 3:32 AM

Ok let me have another shot at explaining this...I need some sort of response as I have spent many hours trying to figure it out with no luck!!!

1. I have a schema defined as an envelope.

2. I have created a custom receive pipeline with a custom XmlDissasembler component in the Dissasemble stage that inspects the xml message (an attrubute of the root node) and promotes this value into a custom property into each debatched message inside the getNext() method.

3. I then have a ESBItinerary and ESBDispatcher component in the Resolve Party stage.

4. In the ESBItinerary component I have a BRE.EXT policy and several rules based on the ESBMessageContext property and the promoted property from 2. I then set the ItineraryName based on these rules.

5. A one-way receive port and a file receive location that uses this pipeline (above)

6. All the itineraries are one-way and invloke a dynamic one-way send port. OnRamp > Messaging Service (map) > OffRampExtender > OffRamp

7. One-way dynamic send port with an ItinerarySend Pipeline.

Ok so far so good. Dropping a message with lets say 3 messages for debatching creates 3 biztalk messages and each uses the correct itinerary. Lets say for this example each debatched message is of Type X and has a promoted property of Y. According to the rule this would evaluate to Itinerary A - and it does and everything works as expected. This makes sense to me because the ESBItinerary and ESBDispatcher components are in the ResolveParty Stage after the Dissasemble stage where the original message is debatched.

Now....If I change the message so each debatched message is of Type X and has a promoted property of Z. According to the rule this would evaluate to Itinerary B - but NO Itinerary A is still used for all 3 messages. The only way to fix this is to restart the host instance.

Something is cached (confirmed using debugView) and I dont know why. It is important that I have only one receive location (using the BRE to evaluate the itinerary to use). Each message coming to the RL is of this envelope schema instance so that is why I only have one RL.

I have tried modifying timeout values in the esb.config file as well as the itinerarySend Itinerary cache component in the Send Port with no luck - although as I understand it this component is only used in 2-way ports.