- This topic has 11 replies, 1 voice, and was last updated 6 years, 11 months ago by
.
-
Posts
-
-
In the past, I have posted some code that we use to add XML \”chunks\” to an existing XML message. This is a C# static function that we call in an expression shape.
In the last few weeks, we have had sporadic cases where the data in this XML message is missing the new elements.
It dawned on me that messages are supposed to be \”immutable\” and we are in effect \”cheating mother nature\”. I think that sporadically, Biztalk dehydrates, then maybe is rehydrating with the old version of this message – before we called the C# helper class.
1) Do you think this is reasonable?
2) Is the solution to simply wrap the C# with an Atomic Scope shape? I.e. will this cause Biztalk to a better \”save point\” for the message?Thanks,
Neal Walters-
But what if I am in a loop, that might loop 3 or even 8 times?
I can’t hard code msg1, msg2, msg3, msg4, msg5 etc…Isn’t there a trick that in a loop, you can construct the same message with the same name?
Thanks, we need to advise on a solution ASAP.
Neal
-
http://www.traceofthought.net/PermaLink,guid,c36b9441-261a-4b7b-b927-bbdc9a5e3c9d.aspx
[quote:a5ce8d5c8f]Recall that persistence will occur when messages are sent, when another orchestration is started asynchronously (like via the Start Orchestration shape), when an orchestration instance is suspended, when a host instance does a controlled shutdown, when a \”wait\” state occurs (like a blocking receive or delay shape that makes the schedule a candidate for dehydration), or when the orchestration completes.
It will also occur at the end of a transactional scope to assist with resuming in an unambiguous state (and executing compensation logic.)
So…although the introduction of an atomic scope prevents serialization within the scope, it introduces serialization at the end of the scope. This is often a persistence point (read: database hit) you wouldn’t have had to live with — if an atomic scope was introduced purely to get around the compiler error above.[/quote:a5ce8d5c8f]
If the above is correct, I’m thinking the \”Atomic Scope\” may be the best way to solve my problem, i.e. it sounds like it forces a persistent point.
Also based on the quote above, I suppose I could:
1) send the message to the NullAdapter
2) pass the message to a dummy orchestration that simply returns
3) use the atomic scope around the expression that changes the messageAny advice appreciated.
Neal
P.S. Biztalk doc says basically the same:
Points
The orchestration engine saves the state of a running orchestration instance at various points. If it needs to rehydrate the orchestration instance, start up from a controlled shutdown, or recover from an unexpected shutdown, it will run the orchestration instance from the last persistence point, as though nothing else had occurred. For example, if a message is received but there is an unexpected shutdown before state can be saved, the engine will not record that it has received the message, and will receive it again upon restarting. The engine will save the state in the following circumstances:The end of a transactional scope is reached.
The engine saves state at the end of a transactional scope so that the point at which the orchestration should resume is defined unambiguously, and so that compensation can be carried out correctly if necessary.The orchestration will continue to run from the end of the scope if persistence was successful; otherwise, the appropriate exception handler will be invoked.
If the scope is transactional and atomic, the engine will save state within that scope.
If the scope is transactional and long-running, the engine will generate a new transaction and persist the complete state of the runtime.
A debugging breakpoint is reached.
A message is sent. The only exception to this is when a message is sent from within an atomic transaction scope.
The orchestration starts another orchestration asynchronously, as with the Start Orchestration shape.
The orchestration instance is suspended.
The system shuts down under controlled conditions. Note that this does not include abnormal termination; in that case, when the engine next runs, it will resume the orchestration instance from the last persistence point that occurred before the shutdown.
The engine determines that the instance should be dehydrated.
The orchestration instance is finished.-
-
I have added a four minute delay to force dehydration and the data loss problem. I then added atomic scope around call to xml-helper \”Add child\” and still having the problem. My next step is to try sending the message to dummy port – I’ll keep you posted. Any idea why the atomic scope didn’t solve the problem?
-
-
To complicate matters, I’m passing a message by ref to a called-orchestration. It adds to this message, but when we come back from the sub-orch and display the message it looks fine.
I added a two-minute delay, and also shut-down Biztalk during this delay.
Immediately after this delay, the message is wiped out – even when I did the following:
1) added a dummy atomic scope after displaying the message coming back from the sub-orch.
2) added a send shape and send the message to our dummy port (that we use to init. correlations). The message in the flat file looks fine.But after the delay and the loop, the same message is back to its previous state.
To everything I read in the doc. about \”persistence points\” doesn’t seem to be applying here.
Any suggestions? This has taken all day and is a serious problem for us.
Thanks,
Neal-
Here’s one more chunk of info –
I display the message before after the delay (where I shutdown biztalk), and it’s actually ok there. This is all inside a loop, and it’s at the beginning of the loop where the message first appears bad.-
Here’s what is apparently happening:
1) The C# routine I call both updates the XMLDocument object passed to it, and also returns an XmlDocument as a return variable.
2) In Biztalk, we have to be sure to say something like:
msgABC = xmlDoc;
in a construct statement.Apparently, in a few places where we were using the C# function, we did not do this. Thus the message was basically being updated \”by ref\” but a persist point was not being created.
I still don’t understand why the Atomic Scope or Send Shape would not persist it none-the-less.
-
Neal,
I think the only safe way to accomplish this is by always creating a new message instead of trying to modify the existing one. You could have your component take in the original bizTalk message and have it return a new XmlDocument you assign to a new BizTalk message inside a Message Assignment shape.
AFAIK, even the rules engine creates a new message instance underneath the covers when it modifies an XLANGMessage passed in as an argument when invoking a policy from an orchestration.
-
[quote:162b7450bd=\”nwalters\”]But what if I am in a loop, that might loop 3 or even 8 times?
I can’t hard code msg1, msg2, msg3, msg4, msg5 etc…Isn’t there a trick that in a loop, you can construct the same message with the same name?
[/quote:162b7450bd]True, but you might be able to use scopes to take care of that (hard to say without known for sure what you do wiht the message once created), by having the message variable be defined inside a scope inside the for-loop shape.
-
-
-
-
-
-
-
-
-
-
I’ve done loops and reused the same message type before without any problems. I’m not a big fan of static method calls inside an Orchestration (for anything other than trivial tasks that is). I have had problems with them in the past. I’m guessing it’s a problem with your static method and dehydration. But that’s just a guess
-
- The forum ‘BizTalk 2004 – BizTalk 2010’ is closed to new topics and replies.