Forum Replies Created
-
Posts
-
Hi Greg,
I have now solved the problem I had with the 405 error, but this is now the error I get: error: The remote server returned an error: (401) Unauthorized.
I searched it up and the suggestion is to go into the biztalk admin console and changes the security settings under the send port's properties box. The problem I have now is that when I right click on the send port there is no properties tab listed. How do I change the send ports security setting to NTLM?
Thanks,
Sharon
I think there should always be an event in the event log. If not, you might have some other problems. I have always seen a few warnings follow by the shut down error.
There might be a WMI Event on a Receive Location shutdown.
You could always write some custom code to query the active Receive Locations and check them against a list of what should be running.
I finally got it to work…..I had to use the format
@"FILE//\\ServerName\DataDirectory\"
i.e
SupplierCode = System.Convert.ToString(POIn(HSSSchemas.PropertySchema.SupplierCode));
OrderNumber = System.Convert.ToString(POIn(HSSSchemas.PropertySchema.BuyersOrderNumber));
POOutPort(Microsoft.XLANGs.BaseTypes.Address)= @"FILE://\\BiztalkMitcham\Data\PO\OUT\" + SupplierCode + @"\O" + OrderNumber + "TEST.xml";
Unfortunately we don't use MOM. We tried to monitor EventLog, but sometimes there is no alerts when some receive location were disabled.
Does anybody know how MOM monitor the receive locations? Does it just watch EventLog?
A long running transaction is not controlled by the DTC and it's not a 2-phase commit one. Hence, there is no inherent rollback capabilities and you need to use the Compensation facilities in BizTalk to implement it by "undoing" your actions manually.
Because of this, usually a long running transaction will be composed of a set of discrete steps, some of which can be "independent" atomic transactions.
As for the serialization stuff, that's because an orchestration cannot be persisted during an atomic transaction (it can be persisted before the transaction begins or right after it commits, but not right in the middle). Because of this, you can safely declare and use non-serializable types within an atomic scope.
a long running transaction can contain atomic transaction why and one more qustion is that non-serializable methods are called only in atomic shape what is the reason
thanks in advance
Hi
I found the solution working with a trick, in the internal xml (xml2) I replace the "<" with "<" and the ">" with ">" With these little changes I obtain a correct string in the element of xml1 and when I extract the xml2 to a XMLDocument works fine.
Bye!
To catch an exception you put the parts that can throw the exception inside a Scope shape, and then right click on the scope shape and select the Add Exception Handler option from the context menu.
One thing to add to Stephen's response is that you can actually sort of do a "sync call" of an orchestration using direct binding, by using direct binding with a request response port, and having the call orchestration return the response message when it is finished. I've used this pattern successfully and it is quite powerful.
One of the benefits of using direct binding is that if you use it correctly you can use it to decouple the calling orchestration from the called orchestration, and this can be a great help when versioning your solution if you design it correctly to take advantage of it. Also, because with direct binding you're using the BizTalk Pub/Sub engine to select the right orchestration to spawn, you can use it alongside custom context properties to "dynamically" choose which orchestration to call instead of having it hardcoded on the parent orchestration. There are a lot of really cool things you can do with this capabilities.
One sample that shows off the direct binding capabilities in BizTalk 2006 in a great way is the BPM Sample Scenario included in the SDK; check out the documentation on it to see how they enable advanced extensibility, versioning and scalability by using reverse direct binding.
There isn’t really a guideline. I think it boils down to what you want to do in the future.
First off, Call Orchestration is a Sync call so it will wait until the next Orchestration finishes to complete the calling Orchestration. Start Orchestration will be a ASync call. With both of these, you need to hard code your Orchestration including the version (if I remember right).
With Direct Binding, you have a lot of flexibility if you want to change out Orchestration later on. Plus these are always ASync except a subscription must be matched or you will be an exception.
If I didn’t need the call to be Sync, I’d probably use direct binding.
Hope this helps.
