Wednesday, August 04, 2004
I discovered a weird problem recently when deploying a BAM definition spreadsheet using the bm.exe program.
Basically, I was getting multiple message boxes containing fn_GetString in the title, plus some other blank message boxes until finally the process ended. It looked pretty terminal!
The problem turned out to be that on my machine the locale was set to English (United Kingdom) and it looks like the BAM deployment process doesn't like it. The message boxes look like they come from Excel so I guess the BAM Excel spreadsheet macro code is to blame.
Changing the locale to English (United States) solved the issue and the bm.exe program was able to export the BAM definition XML successfully from the spreadsheet.
However, I came across another problem. I was running the bm.exe program from the folder that contained my spreadsheet. This folder is different to the BAM folder in the installation folder: \Program Files\Microsoft BizTalk Server 2004\Tracking. An error occurred which said that it couldn't find the BamConfiguration.xml file in the current folder. It seems that it created it back in the BizTalk installation folder, so no wonder!
So, I copied the spreadsheet into the Tracking folder of BizTalk, ran the BAM deployment and it worked!
So I guess the morale of this tale is don't try and be creative with the tools. As long as you live in the US and don't try to do silly things like create application folders to store custom BAM spreadsheets, then you'll be fine ;-P
I've just realised that the BamConfiguration.xml file is a settings file for BAM! Doh! Thanks also to Carlo for pointing that mistake out as well :)
Monday, August 02, 2004
Looks like the documentation has been refreshed again on the 30th July. See post below for the link.
Sunday, August 01, 2004
This was an error that came up recently on a project with a client in sunny Rochdale in the UK. Basically, the orchestration failed with the following error message:
Received unexpected message type '' expected message type '%s'
In effect, orchestration had received a message that had not been resolved to a message type, hence it was unable to understand it. The %s placeholder contained the name of the message type that it was expecting.
This was quite confusing at first because the message that was being returned to BizTalk by way of a solicit-response port was correct according to the schema. Everything looked as if it should match up!
After scratching our heads for a bit, we discovered that the response properties of the solicit-response messaging port was using the Passthru pipeline. This pipeline will not resolve the incoming message against a message type stored in the database! Changing the pipeline to the XMLReceive pipeline did the trick, and orchestration was able to receive the message as a response correctly.
Now, I don't pretend to understand this, so if someone can enlighten me, I would appreciate it :)
I have a web port type defined in orchestration to a OneWay web service. When I create a port based on the web port type and I select Specify Now in the port configuration, then the Delivery Notification property doesn't appear. If I go into the port properties window and change the binding to Specify Later, the Delivery Notification property appears! Change the binding back, and it disappears again! Eh?
My guess is that the delivery notification property is implicitly set when using the SOAP adapter (which is the default using a web port type and specifying the binding in the orchestration), therefore the reason why the property disappears from the property window. By setting the binding to specify later, it is unknown what adapter will be used, therefore offering the delivery notification property to be changed. From what I understand, if a SOAP fault occurs in the SOAP adapter, the SOAP fault is automatically returned to BizTalk, so would explain why the property doesn't appear if the adapter used is SOAP when specifying the binding in orchestration.
However, my dilemma is that I've specified that the web service is OneWay (which the port type understands and only offers a request message to bind to). In this instance, I have no response, but would still like to know if the adapter was able to deliver the request, hence the reason for using the delivery notification mechanism in this scenario.
Is this a bug? Answers on a postcard please...
Imagine a scenario where you have an orchestration exposed as a web service that has two public ports. Each port accepts a message of the same type, but one port is used to send new messages, and the other is used to send update messages. The port type for the port has an access modifier of public, is a request-response port type, plus has a Fault message defined in addition to the request and response messages.
In the orchestration, you create a listen shape and then add two activatable receives - one on each branch with one pointing to the request message of the new port, and one to the request message of the update port. So far so good.
At this point you're going to want to create a couple of send shapes in order to send back either a request message or a fault message. However, as I've just discovered, there's a slight catch, and it is this:
You have configured a scope shape with an exception handler block in each of the listen branches. You have it configured such that at the end of the scope you send back a response message and in the exception handler block you return a fault message for BizTalk to wrap in a SOAP exception and return to the client. This seems perfectly reasonable on the face of it. The problem occurs at compilation time.
The compiler basically barfs with must receive before sending a fault message on an implemented port. What? Well, I've certainly performed a receive before sending, so why is it complaining? If I move the send of the response after the end of the scope but still within the listen branch, then it now barfs with must receive before sending a message whose messagetype corresponds to a requestresponse operation on an implemented port.
It appears that it doesn't like having two send shapes where one may execute before the other, therefore nullifying the receive for the second send shape.
So, in order to get around this, you need to put the two send shapes (response and fault message sends) in either branch of a decision shape. So, at the end of the scope, set a flag to indicate success and in the exception handler set the same flag to indicate that a fault has occurred. Then, after the scope, create a decision shape to test the flag and either send the response or send the fault.
Just out of interest, I moved the decision down in the orchestration until it was after the end of the listen shape (that is, it wasn't directly in any of the branches of the listen shape, but just located 'after'). In this case I get both of the compiler errors detailed earlier which is quite interesting. Probably as a result of the fact that it could have been possible to exit the listen from another branch, thereby not executing the receive shape for which we're returning a response.
I was asked the question recently: how can I return a SOAP fault from a web service call if the orchestration that has been published has failed?
Well, this is seemingly a lot easier than you would think. A request-response port type in orchestration allows multiple Fault Messages to be defined. These fault messages can be based on any message type (for example, System.String) and are returned to the web service in the same manner as returning a response to a web service, that is, via a send shape to the appropriate fault message on the operation defined on the port type.
If you were to take a look at the port type definition in the orchestration view tab in VS.NET, then you'll see the various messages defined on the operation of the port type. Each message has an associated icon that represents the message direction:
- blue arrow for request
- green arrow for response
- red cross for fault
By simply creating the appropriate message and populating it, then sending the message to the fault message of the port, you are able to return SOAP faults to the client of the web service. Easy, eh?
Follow this link to download a new update to the product documentation.
However, for some reason, we're having some problems installing it. In addition, why are the following services shut down during a documentation refresh?!
- BizTalk NT Host Instances
- Enterprise SSO
- FTP Publishing Service
- HTTP SSL
- IIS Admin Service
- World Wide Web Publishing Service
Seems a bit overkill to me!! Imagine trying to get away with that in production!