Hi all
I have had on my to do list for ages, that I should start developing some functoids
that might be nice to have.
Well, finally I have started, and my first functoid can be downloaded from http://www.eliasen.eu/DownloadSoftware.aspx.
Note, that the eliasen.eu domain has just been moved from one hosting company to another,
which means that the link might not work for another day or so.
Comments, bug reports, suggestions, and so on are very welcome.
—
eliasen
Yipee!!!!
Check out my new book on REST.
Hi all
I have changed the config of my blog software (dasBlog) so all comments have to be
approved by me. I hate to have to do this, but apparently, the upgrade to a newer
version has made it easy for spammers to write silly comments with links to all sorts
of weird web sites (I guess they are weird – naturally, I have never clicked on one…).
I have already delete 5 inappropriate comments to posts, and they seem to come faster
and faster.
I will ask the programmers of dasBlog to see what is happening, and then disable the
approval flow once I have it solved.
I apologize for the inconvenience.
—
eliasen
Back on the old Microsoft blog, I built and demonstrated a tool that exploits the built-in (but hidden) BizTalk Business Rules Engine API for securing access to business rules.
I have a link to this Rules Authorization Manager on the downloads page of this blog, but up until now, I had only included the executable. After […]
I had the pleasure of being in Barcelona this week for the TechEd Developer conference. Highlights – getting to talk to several hundred developers about WF / WCF / Dublin /Oslo. Lowlights – it’s Barcelona, what could be a lowlight? TechEd capped off the most interesting 8 weeks I’ve ever had in software. In under two months we’ve had major iterations on virtually all the technologies that we drive in CSD. It started out with a roadmap update on BizTalk Server where we provided some more detail on BTS2009 and also talked about the next two major releases.
Next, we announced major updates to WF and WCF and introduced “Dublin”. After that, I hit the road with Robert Wahbe, VP of CSD, our fearless leader. We talked to several RDs and various members of the press about Oslo – and progress we’ve made in the last year. We were getting ready to ship the Oslo CTP and wanted to give folks a sense of how it had developed and what they’d see at PDC.
Two weeks ago at PDC we made good on the promise to provide CTPs on WF, WCF, Dublin, and Oslo (including “M”, “Quadrant” and the Repository). For those scoring at home that’s a promise kept – one year from the Oslo announcement to code. For those of you who didn’t make it to the conference, take a look at Oslo at the new Dev Center or www.modelsremixed.com. Going further, we announced the Azure Services Platform and opened it up to attendees for an early CTP. As a company we’ve spent the last 20 years democratizing the desktop, we’ll spend the next 10 democratizing the cloud.
Last week we kicked off a new “Real World SOA happens {here}” theme. This features a new online video portal that will showcase the successes of our customers around the globe. This update to the web also highlights a set of events that we’re running to broadly connect with thousands of customers worldwide as part of a 20+ city road show. If you’re interested in learning more about SOA and how you can be successful – check out the new site at www.microsoft.com/soa/launch.
I spent some time today looking at Microsoft’s Enterprise Service Bus (ESB) Guidance Toolkit, and this reminded me of an issue which we noticed a year ago, and did attempt to raise with Microsoft at the time, but which I never blogged about. It’s always a little uncomfortable taking the good people at Redmond to task, but, while this is hardly the most urgent problem facing today’s world, it is, nevertheless, a bit of a problem and something which should be addressed.
In the article, I discuss the problem, where the Toolkit goes wrong, how UDDI should be used, and a possible remedy. The article is at http://geekswithblogs.net/cyoung/archive/2008/11/12/126975.aspx.
This has happened to me in the past – sometimes randomly, sometimes consistently. After a quick search I found that all you need to do is make sure you select “Workflow” as the type of code you want to attach to, as described nicely in this article:
How to solve Visual studio crash on attach process for debugging a sharepoint workflow
This is a very specific problem but I’m sure some of you stumbled over it. When disassembling a XML message in a SOAP port BizTalk can’t read the message type. This causes problems when for example trying to handle an envelope message and split it to smaller independent messages in the port. It’s a known problem discussed here and here (you also find information about it in the BizTalk Developer’s Troubleshooting Guide) and the solution is to make a small change in the generated web service class. Below is a small part of he generated class.
//[cut for clarity] ...
Microsoft.BizTalk.WebServices.ServerProxy.ParamInfo[] outParamInfos = null;
string bodyTypeAssemblyQualifiedName = "XXX.NO.XI.CustomerPayment.Schemas.r1.CustomerPayments_v01, XXX.NO.XI.CustomerPaym" +
"ent.Schemas.r1, Version=1.0.0.0, Culture=neutral, PublicKeyToken=ac564f277cd4488" +
"e";
// BizTalk invocation
this.Invoke("SaveCustomerPayment", invokeParams, inParamInfos, outParamInfos, 0, bodyTypeAssemblyQualifiedName, inHeaders, inoutHeaders, out inoutHeaderResponses, out outHeaderResponses, null, null, null, out unknownHeaderResponses, true, false);
}
}
}
Basically the problem is that the generated code puts the wrong DocumentSpecName property in the message context. I’ll not dicusses the problem in detail here but Saravana Kumar does thorough dissection of the problem in his post on it.
The solution is to update the bodyTypeAssemblyQualifiedName to set a null value. That will cause the XmlDiassasemler to work as we’re used to and expect.
>
> If the value _null_ is passed instead of _bodyTypeAssemblyQualifiedName_, SOAP adapter won’t add the _DocumentSpecName_ property to the context. Now, when we configure our auto-generated SOAP_ReceiveLocation_ to use _XmlReceive_ pipeline, the _XmlDisassembler_ component inside _XmlReceive_ will go through the process of automatic dynamic schema resolution mechanism, pick up the correct schema and promotes all the required properties (distinguished and promoted) defined in the schema and it also promotes the _MessageType_ property.
>
>>
> **From:** [http://www.digitaldeposit.net/saravana/post/2007/08/17/SOAP-Adapter-and-BizTalk-Web-Publishing-Wizard-things-you-need-to-know.aspx](http://www.digitaldeposit.net/saravana/post/2007/08/17/SOAP-Adapter-and-BizTalk-Web-Publishing-Wizard-things-you-need-to-know.aspx)
>
>
//[cut for clarity] ...
Microsoft.BizTalk.WebServices.ServerProxy.ParamInfo[] outParamInfos = null;
string bodyTypeAssemblyQualifiedName = null;
// BizTalk invocation
this.Invoke("SaveCustomerPayment", invokeParams, inParamInfos, outParamInfos, 0, bodyTypeAssemblyQualifiedName, inHeaders, inoutHeaders, out inoutHeaderResponses, out outHeaderResponses, null, null, null, out unknownHeaderResponses, true, false);
}
}
}
But if you have an automated deployment process you probably use MSBuild to generate your Web Services. Then is soon becomes very annoying to remember to update the .cs-file again and again for every deployment. So how can we script that update?
First we need to find a regular expression to find the right values. With some help from StackOverflow (let’s face it, there are some crazy regular expressions skills out there …) I ended up on the following.
(?<=stringsbodyTypeAssemblyQualifiedNames=s)(?s:[^;]*)(?=;)
If you’re not a RegEx ninja the line above does something like this:
After the string “string bodyTypeAssemblyQualifiedName = “
turn on single line (treat “rn” as any other character) ( this is what “(?s: )” does)
match every character that is not a semicolon
until a single semicolon is reached.
Then I used a task from the SDC Task library (you probably already use this if you’re using MSBuild and BizTalk). More specially we use the File.Replace
<Target Name="FixSOAPServiceCode">
<File.Replace
Path="$(WebSiteServicePath)CustomerPaymentServiceApp_CodeCustomerPaymentService.asmx.cs"
Force="true"
NewValue="null"
RegularExpression="(?<=stringsbodyTypeAssemblyQualifiedNames=s)(?s:[^;]*)(?=;)">
</File.Replace>
</Target>
Now this task is part of the build script and called right after the tasks that generates the web service. This saves me a lot of manual work and potential errors!
This is a very specific problem but I’m sure some of you stumbled over it. When disassembling a XML message in a SOAP port BizTalk can’t read the message type. This causes problems when for example trying to handle an envelope message and split it to smaller independent messages in the port. It’s a known […]