I have an orchestration with transaction type set to None.
Within the orchestration I invoke a C# helper class which is referenced in the orchestration project.
On building I get the error
a non-serializable object type can only be declared within an atomic scope or service.
To get round this I tried to change the transaction type of the orchestration to atomic, but that won't work as from within it I also have to call another orchestration, which gives the error
an atomic scope may not contain or call a service or scope that contains both the send and the corresponding receive of a requestresponse operation on a 'uses' port or servicelink
Can anyone point me in the right direction here?
Problem solved. Have done the call-orchestration near the start of the main orchestration, then have everything else inside an atomic scope.
#Pieter - thanks once again for looking at another of my Biztalk questions
Related
Trying to fix a problem in a classic ASP application, however I am inexperienced. Tried to find more info but was unable to.
The app instantiates a COM object for data retrieval which is not thread-safe, so the following instructions are added.
comObject=CreateObject("comServer.comObject")
returnValue=comObject.DoWork(.......)
...
comObject = Nothing
However, when processing two different http requests at the same time, the latter one seems to overwrite the first request, giving the first requester an error. It looks as if the comObject variable is shared between the requests.
How to instantiate the object in such a way that every separate request in IIS, gets it's own instance of the comObject?
Without knowing what the object does or how it does it, it's impossible to give specific advice. A general description will have to do:
The object is broken/buggy. It is the object's responsibility to handle the problem.
A COM object is supposed to handle all threading issues internally, or defer to COM STA apartments if it cannot do it, or doesn't want to (for those aspects that an STA can handle). This goes deep into the design of the object.
Regardless of COM Apartment choice, a DoWork(...) method with a semantic that precludes multiple separate COM objects in separate threads from handling simultaneous calls - is a seriously problematic design at best. A proper design would either include mechanisms to handle the conflict explicitly, or just hide the conflict from the calling code and handle the conflict internally.
Depending on the details of what DoWork() does, there might be ways to fix the object in such a way that the calls can succeed in parallel, or block each other so the calls are effectively serialized, or to cause the second call to throw a "You already called me" error. Again, which approach is more appropriate depends heavily on what the method does.
If you can't modify this broken component, your best option would be to write a COM wrapper that ensures serialization to the real object.
In any case, there is nothing reasonable you can do from the client (ASP VBScript) side.
I am using SimpleIOC from mvvm-light along with the ViewModelLocator class / pattern provided to provide ViewModels with the correct dependencies injected. The problem I have is that the dependency that is being injected in to my ViewModel is a WCF ClientBase instance that can "break" if it encounters a fault. One example would be if the service it is trying to connect to doesn't exist it will cause a fault. I don't know how to handle this properly. Once the ClientBase derived class is in a fault state it will no longer work. The ViewModelLocator keeps injecting this broken instance of my service proxy so even if this service becomes accessible the proxy will error out when used because it can't recover from a faulted state. How should I deal with this?
I was able to figure this one out on my own. The answer was to create a wrapper around the ClientBase proxy class so that when a call created a fault, the wrapper class could properly handle the exception yet still be ready to handle the next call.
I would like to do a main orchestration that receive a specific message and with a specific value in this message the main orchestration can call another orchestration (with call orchestration shape) that receive a different message with receive shape and do other function
Note: the main orchestration and the other orchestration is in the same project
in general how can I proceed with 2 orchestration with a receive shape in each one
I think you are heading toward the wrong direction, what you can do is like this.
Create a main orchestration,and receive the message (your specific) from message box.
In your orchestration, check the value you want to check.
When it is necessary to pass the message to another orchestration, you don't call the orchestration direction. create a new message, use a map, to transfer the message you got to the message which another orchestration is listening.
Publish the message back to message box.
In this way, you don't need to call the orchestration directly. BizTalk will help you to schedule and passed message to the orchestration that you want to invoke.
Or you can use a message only solution, which means , you don't need to have a main orchestration at all, you can setup filters on your receive location, and then use map to transfer the message.
I have BizTalk orchestration where it receives file and send file. I have expression shape calling .net class (method) to read xml file and upload file to SharePoint. My expression shape has the following:
XmlReader.readXml();
It's not passing any parameter nor return any value.
My Xml file gets send to send location and generate no error on window logs. However, it's not uploading file to sharepoint. If I run XmlRead.readXml() by itself, I don't have any problem uploading to sharepoint. How do I know if my .net is calling the method and executing?
OK, first thing. If there are no errors in the applications event log and BizTalk does not suspend throwing an exception then you know that your orchestration is working.
The fact that you are not getting the required behavior from it is not down to any biztalk weirdness.
Can you post the code from your expression shape and then it may be easier to find out what your problem is?
I am a little confused by your post because you say you are calling a .net class from an expression shape, but then you have a call to XmlReader in your expression shape. Is XmlReader your own class? If so then you do not seem to be passing any data into your readXml(). This may be why your call does nothing. If you need to pass a biztalk message into a method call from an orchestration you need to use the XLANGMessage type which can be found in the MicroSoft.XLANGs.BaseTypes assembly.
Hope this helps.
How can I call a BizTalk Orchestration dynamically knowing the Orchestration name?
The call Orchestration shapes need to know the name and parameters of Orchestrations at design time. I've tried using 'call' XLang keyword but it also required Orchestration name as Design Time like in expression shape, we can write as
call BizTalkApplication1.Orchestration1(param1,param2);
I'm looking for some way to specify calling orchestration name, coming from the incoming message or from SSO config store.
EDIT: I'musing BizTalk 2006 R1 (ESB Guidance is for R2 and I didn't get how it could solve my problem)
The way I've accomplished something similar in the past is by using direct binding ports in the orchestrations and letting the MsgBox do the dirty work for me. Basically, it goes something like this:
Make the callable orchestrations use a direct-bound port attached to your activating receive shape.
Set up a filter expression on your activating receive shape with a custom context-based property and set it equal to a value that uniquely identifies the orchestration (such as the orchestration name or whatever)
In the calling orchestration, create the message you'll want to use to fire the new orchestration. In that message, set your custom context property to the value that matches the filter used in the specific orchestration you want to fire.
Send the message through a direct-bound send port so that it gets sent to the MsgBox directly and the Pub/Sub mechanisms in BizTalk will take care of the rest.
One thing to watch out in step 4: To have this work correctly, you will need to create a new Correlation Set type that includes your custom context property, and then make sure that the direct-bound send port "follows" the correlation set on the send. Otherwise, the custom property will only be written (and not promoted) to the msg context and the routing will fail.
Hope this helps!
Look at ESB Guidance (www.codeplex.com/esb) This package provides the functionality you are looking for