Forum Replies Created
-
Posts
-
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?
Dayo,
Usually, you’ll create a user account that is a member of the \”BizTalk Isolated Host Users\” group, and you’ll use that as the identity for your appPool. It’s really not different than the service account you create (member of the \”BizTalk Application Host Users\” group) to run your BizTalk Application Hosts.
The 500 server error might mean a number of things, including that the message was received but no subscribers where found; it’s not just that no access to the databse was allowed. You should take a look at the server’s Application Event Log, you should find more detailed information about the error there.
Thanks for replying.
The issue here is that the MSG A contains the data that will be used to
\”grab\” the right MSG B. In other words MSG A sets the correlation for
the consequent MSG Bs.If I parallel the first receive how will i be able to set the correlation?
Mind you that this is a pattern of re-batching in which the correlation
data is set with a different message and therefore the NON-UNIFORM
title.>From what read in the documentation this would be possible.
Thanks,
FP
Hi
The application pool now runs under the identity of the \”biztalk isolated host instance\” account. But now all I get is a \”500 Internal Server Error\”. I have done some searching and found that you get this error because the identity running the Application Pool does not have access to the biztalk databases and therefore has to be added to the Biztalk Isolated Host Users Group, which I’m sure the \”biztalk isolated host instance\” account is.
Any other ideas?
CheersI think you need to build the 2nd method in debug mode to get the symbol file. I think then that will work.
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.[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.
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
David,
You do this by using the Wrap Character property.
I cover this in my BizTalk FF tutorial which actually covers writing schemas for CVS files:
http://www.winterdom.com/dev/bts/BTSFFSchemaTut1.html
(see towards the end)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.
I had the same problem, see
[url]http://www.biztalkgurus.com/forums/viewtopic.php?t=560&highlight=[/url]
The problem is that BizTalk2004 needs enough unfragmented memory to process the file.
We use now BizTalk2006.
That solve our problem.The PipelineObjects.dll library is included with BizTalk, it will be in the same directory as the Pipeline.exe tool you were using before.
For an example of using it with NUnit, check the included unit tests for the library itself; they are writen using NUnit. Just take a look at the Winterdom.BizTalk.PipelineTesting.Tests project.
To use NUnit, all you need to do is fire up the NUnit GUI tool, and load the test library you created and run it. For information on using NUnit itself, check out http://www.nunit.org/index.php?p=quickStart&r=2.2.8
Finally, if you don’t feel comfortable using NUnit, that’s OK. just write a simple console program that calls the library to do the test you want; it will work just as well!
I’ll try your library, but I have some problems with it.
First the reference ‘PipelineObjects’ from Winterdom.BizTalk.PipelineTesting will not be found. To which DLL/component does it refer?
And second, how do i start the project from VisualSudio2005 with NUnit?
You should know that this is my first project with VS and i had never written a dll before. 🙁
My last programs are simple C console programs and that was long time ago.
