by community-syndication | May 23, 2008 | BizTalk Community Blogs via Syndication
My article on “smart” use of XSLT within BizTalk appeared in BizTalk
Hotrod Issue 4. Once again, a great set of content thoughout this issue.
The article talks about the “why and how” of using a “straight”
XSLT approach with BizTalk – where your XSLT files reside directly on disk,
and not within map assemblies. It discusses caching compiled XSLTs, and using
XSLT 2.0 via the Saxon libraries. You can download the sample code and comment
over on the article’s Codeplex project.
by community-syndication | May 23, 2008 | BizTalk Community Blogs via Syndication
We still have a few seats left for our upcoming Double Feature: WCF + WF events. For those new to our Double Feature offerings, the concept is simple: we cover almost two complete 4-day courses (WCF + WF) in one extended hours 5-day week. We call it the firehose methodology.
If you’re looking to ramp-up on both of these emerging Connected Systems technologies in the most efficient way possible, take a look at this offering. It’s a great way to maximize the ROI on your limited training/travel dollars, especially in today’s economy.
The next event is in Irvine on 6/16. If that doesn’t work for you, we’re also holding one in London on 7/14, another in Chicago on 8/4, and another in Waltham on 9/22. You can save yourself a seat right now without any obligation (simply click “Save a Seat“ instead of “Register Now“).
I will be teaching the Irvine course with Jon Flanders and Chicago with Matt Milner.
by community-syndication | May 22, 2008 | BizTalk Community Blogs via Syndication
The presentation made available for download through this post is in swedish. The code however is "international". First of I would like to list what I think are two of the best getting started with LINQ resources available online. The free…(read more)
by community-syndication | May 22, 2008 | BizTalk Community Blogs via Syndication
The latest issue of the BizTalk HotRod magazine is out. Some of the topics you’ll find are:
Detailed look at using the ESB Guidance Exception Management framework
Exposing BizTalk BRE rules via WCF services
Look at parallel convoys
Peek at the BizTalk WCF adapters
Taking control of XSLT in BizTalk solutions
Hosting WF in BizTalk
And much more. As usual, a well […]
by community-syndication | May 22, 2008 | BizTalk Community Blogs via Syndication
Here is the scenario to create this error:
You are batching outbound EDI documents, you have enabled the extended validation.
Resolution or Workaround:
=====================
The workaround is to disable extended validation of the batched messages. Product team will fix this in the next version of the product.
by community-syndication | May 22, 2008 | BizTalk Community Blogs via Syndication
BizTalk Server has some pretty strong facilities for making a "best effort"
at ensuring message delivery, by using the automatic retry facilities available to
BizTalk Send Ports.
This functionality is available when calling Web Services as well either with the
WCF or SOAP adapters, and it’s very useful. However, it’s not always enough by itself.
One such scenario comes up when the Web Service you’re calling does not return SOAP
Faults when it fails, but instead returns some kind of status/result indicator as
part of a normal response message. In that case, the SOAP/WCF adapter can’t tell on
its own that the service call failed and retry it as necessary.
There are a few ways you can deal with this.
For example, you can handle retries manually from an orchestration, using a Loop shape
to call the service, check the result and retry the call as necessary. It’s not complex
(though a bit cumbersome) and in many scenarios works very well.
Unfortunately, this isn’t an option if you are in a messaging-only scenario, or have
complex routing rules leading to the service invocation (common with direct-binding
scenarios).
One possible workaround for this if you’re using the WCF Adapter in R2 that I’ve been
experimenting lately with is to use the WCF-Custom adapter and configure a custom
Endpoint Behavior that adds an IClientMessageInspector implementation
that checks the response message and transforms it to a fault if it indicates.
A few things to keep in mind if you decide to try this:
-
For your behavior to be listed on the BizTalk Administration console, you’ll need
to implement a BehaviorExtensionElement for
it, deploy it to the GAC and register it in machine.config (or at least this was the
way I did it).
-
Inside your
IClientMessageInspector.AfterReceiveReply() implementation,
you might need to create a buffered copy of the message and return a new Message instance
built from it to the WCF Adapter runtime; otherwise BizTalk might not be able read
the message because you’ve already consumed it and it will be in the closed state
by then.
-
Make sure you leave the "Propagate Fault Message" option unchecked; otherwise
your fault will just be submitted to BizTalk as a regular message and won’t cause
the send port to retry the call.
My friend Carlos suggested that
another way to deal with this issue (particularly if you’re not using the WCF adapter)
might be by building a custom pipeline component and using it in a receive pipeline
configured in the Send Port. The component would then read the response from the Web
Service and throw an exception to force a failure during the response processing if
necessary, thus causing the entire exchange to fail. I haven’t tried this myself,
but sounds like another useful idea!
BizTalk
Server 2006 R2, WCF, Web
Services
by community-syndication | May 22, 2008 | BizTalk Community Blogs via Syndication
For those that are aware of the BizTalk Hotrod magazine will know how informative and jam-packed this resource is. Those of you who are new to the Hotrod will marvel at the amount of content available in this freely available download.
Here’s some more detail on the contents of this issue, from Todd van Nuurden, the self-proclaimed “Pirate Technology Specialist”, as posted at http://biztalkhotrod.com/default.aspx:
Hi BizTalk Fans,
Its finally Spring here at BizTalk Hotrod HQ and Issue 4 has finally been put to bed! In this issue you’ll see that we’re continuing our expansion into WF (Windows Work Flow) and WCF (Windows Communications Foundation). Why, you ask, would we do this? Well BizTalk is the future! And we want to bring our .NET friends into the BizTalk fold and as you’ll see BizTalk continues to expands its process server capabilities across the Microsoft platform. We’ve also expanded our coverage to include folks new to BizTalk Server so check out Sal’s “In the Beginning” article
As always we’re looking for new ideas and new authors so if you’re interested please contact us.
Oh we’re also considering a BizTalk Hotrod Resource issue that would include articles by BizTalk software partners as well as links to all the coolest BizTalk Content on the web. So if you have content that we should link to or publish let us know.
Issue 4 of the Hotrod is now available at http://cid-b6c859f7a5f75e63.skydrive.live.com/self.aspx/Public/Q2FY08_biztalk.pdf. Go and get it!
by community-syndication | May 22, 2008 | BizTalk Community Blogs via Syndication
In my previous post on the default behaviour of the XMLReceive pipeline with respect to validating a message against a schema I detailed the creation of what I termed the "XMLValidatingReceive Pipeline". In response to this posting, Payal Arya emailed me the following question with respect to this posting, which highlighted the need for more clarity around how the pipeline works:
"Your posting was very helpful, however I had one question that what’s the use of XML Disassembler and Party Resolution in the Pipeline, when only XML validator solves the purpose."
After getting this question, and reading through my post again I clearly did not detail the reasoning for the use of these components, so here goes.
The reason why I kept the XML Disassembler and Party Resolution components in the pipeline is that I wanted the standard XML Receive pipeline to be enhanced with an automatic schema validation function. This would then provide me with an enhanced, generic pipeline I would be able to use in any development that required schema validation. This required that I keep the same functionality that the XMLReceive pipeline provided, and just extend its functionality: so that the XMLValidatingReceive pipeline effectively becomes an evolution of the XML Receive pipeline’s generic functionality.
The alternative, if you wanted the simplest pipeline that would still do schema resolution and validation, would be to create a pipeline that just has the Xml Validator component in the pipeline. As the Xml Validator component will automatically resolve the schema from the message’s target namespace and root node name, it would be able to identify the schema associated with the received message, and then perform the validation as well.
By keeping the XML Disassembler component in the pipeline, however, the pipeline will still support any envelope and debatching processes embedded in the schema design, and the debatched messages would then be validated by the Xml Validator component. Similarly, by including the Party Resolution component, any party resolution logic that you may require in your solution is still supported. Obviously, if you do not require either of these functions in your solution and you do not want to incur the overhead of these additional components you could exclude these pipeline components, and your pipeline would still perform the validation function.
by community-syndication | May 21, 2008 | BizTalk Community Blogs via Syndication
by community-syndication | May 21, 2008 | BizTalk Community Blogs via Syndication
Back in V2.0 we had a Web Service that did this sort of stuff for us, now in V3.0
it’s delivered straight from the Object Model.
Essentially:
-
We create a batch of XML which could have ‘adds, updates + deletes’ in there.
-
We call the web.ProcessBatchData(xml) method, handing to it our wishes.
This technique is fast, and CAML based 🙁
So if you need to add 100 items to the list – this would be a way to do it. (I’ve
got to check whether this technique fires event handlers on the lists or whether it’s
a ‘back door’ thing)
Note: in the snippet below, the fields are referenced via their namespace#<name>
– you can get the field’s details by saving your list ‘As a template’,
downloading the *.stp file, renaming to *.stp.cab, opening it and looking into the
*.xml file there.
– you could also call the lists.asmx webservice (..\_vti_bin\lists.asmx)
and calling the GetListCollection(); method to see a chunk of describing
XML.
1: "<ows:Batch
OnError=\"Return\">" +
2: "<Method ID=\"A1\"><SetList>" +
myGuid + "</SetList>" +
3: "<SetVar Name=\"ID\">New</SetVar>" +
4: "<SetVar Name=\"Cmd\">Save</SetVar>" +
5: "<SetVar Name=" +
6: "\"urn:schemas-microsoft-com:office:office#Title\">" +
7: "New Manager</SetVar>" +
8: "<SetVar Name=" +
9: "\"urn:schemas-microsoft-com:office:office#Body\">" +
10: "Congratulations to Mary for
her promotion!</SetVar>" +
11: "<SetVar Name=" +
12: "\"urn:schemas-microsoft-com:office:office#Expires\">" +
13: "2003-09-14T00:00:00Z</SetVar>" +
14: "</Method>"
.csharpcode, .csharpcode pre
{
font-size: small;
color: black;
font-family: consolas, “Courier New”, courier, monospace;
background-color: #ffffff;
/*white-space: pre;*/
}
.csharpcode pre { margin: 0em; }
.csharpcode .rem { color: #008000; }
.csharpcode .kwrd { color: #0000ff; }
.csharpcode .str { color: #006080; }
.csharpcode .op { color: #0000c0; }
.csharpcode .preproc { color: #cc6633; }
.csharpcode .asp { background-color: #ffff00; }
.csharpcode .html { color: #800000; }
.csharpcode .attr { color: #ff0000; }
.csharpcode .alt
{
background-color: #f4f4f4;
width: 100%;
margin: 0em;
}
.csharpcode .lnum { color: #606060; }
Here’s a small MSDN article on it – http://msdn.microsoft.com/en-us/library/cc404818.aspx
Cheers,
Mick.
