by community-syndication | Jan 24, 2006 | BizTalk Community Blogs via Syndication
Today’s tip is brought to you via the BizTalk 2006 Deep Dive training course that I’m on, run by Alan Smithof the Bloggers’ Guide to BizTalk fame..
In BizTalk 2004, if you wanted to create an empty output element in your target document via the mapper, you had a couple of options. You could either use a string concat functoid with one empty input parameter, or use a value mapper with ‘true’ and an empty string as its inputs. Bit tacky really, and in the case of a string concat also a bit slow as it uses inline C#.
Well rejoice, for in BizTalk 2006 there’s a new drop-down option on the “Value” field of the mapper that lets you pick “”.
Lovely! Especially handy if you are using the little-known but amazingly handy Property Demotiontechnique to populate message fields on the way out.
Incidentally, further to the system context properties described in the link above, you can also demote your own promoted properties from your own custom schema back into your message in the send pipeline.
by community-syndication | Jan 23, 2006 | BizTalk Community Blogs via Syndication
Hi all. Hope everyone watched as the Seahawks pummelled the Carolina Panthers yesterday. For our remote team members out in Charlotte … ouch … 6 total yards in the first quarter … ouch (I know it hurt Brian :). However, on a positive note, the Biztalk team is growing and has a lot of cool new work to do which we are planning right now. The bad news, though, is that you would probably at some level have to work with me. If you can get past that and are interested … the official blurb is below. Thx. Go Hawks!
We have several open positions in BizTalk team. We just started planning our next release of BizTalk server and have a lot of exciting ideas and opportunities. Send email to kerryv@microsoft.com if you want to participate in building next generation of the BizTalk server, or know someone who can be interested in growing his/her career in Microsoft.
by community-syndication | Jan 23, 2006 | BizTalk Community Blogs via Syndication
Exposing BizTalk interfaces as webservices is very easy using the ’BizTalk Webservice Publishing Tool’. In almost all cases this tool generates a correct functioning web service which does not need any code modification.
However, there are situations where tweaking the code of the generated web service is necessary. Recently I needed two different BizTalk interfaces to expose the exact same WSDL. Because the two interfaces had different names for namespaces and artifacts, the generated webservices and WSDL were not the same.
You can solve this by using the SoapExtensionReflector. The BizTalk Webservice Publishing Wizard generates a class called ’WsdlExtensions.cs’ for every webservice that is generated. By including this file in the generated VS.Net webservice project and adding the type in the ‘soapExtensionReflectorTypes’ section of the web.config (see header comments of
WsdlExtensions.cs), you’re able to control the generated WSDL for the webservice.
By default this file is generated with code for XML schema replacement in the WSDL, but you can use this to change other parts. For example, to override the SOAP service name, you can use:
public override void ReflectMethod()
{
ProtocolReflector reflector = this.ReflectionContext;
reflector.Service.Name = “MyNewServiceName”;
}
After recompiling the web service the service name in the WSDL is changed to the new value.
by community-syndication | Jan 19, 2006 | BizTalk Community Blogs via Syndication
I am working on a 56 processor (yes, that was FIFTY SIX PROCESSOR) BizTalk project for a very large company in the Bay area. As far as I know this is the largest BizTalk project on the go right now on the planet. I’m going to start blogging about our experiences as we move through this project, as I suspect lots of you BizTalkers will be *highly* interested in the challenges we are facing and how we are meeting them.
My role is architectural and tech lead for the BizTalk development side, I am responsible for the design and development of what is being called the “core engine”. There are MANY people working on this, on both the Java and .NET sides.
So what are we building? Well, I’m working in the ESB department, and everyone says we’re building an ESB. This makes perfect sense at the client site, but gets somewhat cloudy when you’re outside of the company, as there are multiple, sometimes conflicting, definitions of what an ESB really is. Many companies outside the Microsoft space have a product (or suite of products) that they call an ESB. In the Microsoft space, where I play, there is no single product that “is” an ESB. Rather, what most people define as an ESB is in fact a subset of what you get with the Microsoft technology stack.
There is an excellent position paper on Microsoft’s view of ESB available here
.
The key message in that paper, in my opinion, is: While Microsoft does not believe ESB is a stand-alone product category, customers looking to purchase an ESB will find that Microsoft offers a significant superset of ESB functionality at competitive price points.
To further quote from that paper, some of the common characteristics of the various ESB definitions include:
- Brokered communication. The basic function of an ESB is to send data between processes on the same or different computers. Like message-oriented middleware, the ESB uses a software intermediary between the sender and the receiver, providing a brokered communication between them.
- Address indirection and intelligent routing. ESBs typically include some type of repository used to resolve service addresses at run time. They also typically are capable of routing messages based on a predefined set of criteria.
- Basic Web services support. A growing number of ESBs support basic Web services standards including SOAP and WSDL as well as foundational standards such as TCP/IP and XML.
- Endpoint metadata. ESBs typically maintain metadata that documents service interfaces and message schemas.
To distill it down further to the simplest level, the basic idea is that you send a message to the ESB, and the message automagically gets routed to an end-point, perhaps with an optional transformation happening along the way. The endpoint could be just a protocol hop, or it could be a complex business process, or something in between. This can be thought of as a “services messaging layer”, or you could call it ESB-like. For my client, it will provide a core set of services that will be used across the enterprise for application integration, and will do so in a highly-scalable, reliable and extensible services-oriented manner.
It is my intention to post here on a regular basis, making this a true “living diary” for the project. I will be talking about the issues we run into, and how we solve them. I’ll walk you through the architectural decisions we’re making, and explain why. There are “soft” issues around this too, such as documentation, rollout plans, training… I’ll be writing about those also. This will be full-spectrum coverage. We’re facing and solving some tough engineering and business problems, and I am sure that a lot of what we’re up against will be very relevant to others that follow with similar projects.
Having said all that, this is a blog, and I’ll be posting entries as time permits. I’m thinking I’ll likely be writing blog entries nights, and while traveling (which I do a LOT of nowdays). Also, should I go dark for a while, that probably means that I’m spending all my time on the development effort. If that happens, I’ll make sure I catch up!
by community-syndication | Jan 18, 2006 | BizTalk Community Blogs via Syndication
Tip: temporarily commenting out chunks of an orchestration
Some of you will read this and say “doh, isn’t that obvious to everyone?”. Others will smack their foreheads and say “hey, what a cool tip”. So, to half of you: sorry to state the obvious, and to the other half: you’re very welcome.
Often while developing an orchestration it may be useful to “comment out” some of the steps. But… there is no “right-click route-around-this” capability on shapes, so what can you do?
You could make a copy of the orchestration, but a simple/easier/faster way is just through in a “decide” shape, make the condition “true==false”, then drag the shapes you want out of the flow into the false branch.
Of course, everything still needs to be compileable….
by community-syndication | Jan 16, 2006 | BizTalk Community Blogs via Syndication
I’ve been tracking the CCR internally within Microsoft for a while now, and now there’s an interesting channel 9 interview with the CCR guys: http://channel9.msdn.com/Showpost.aspx?postid=143582 if you’ve ever done any amount of concurrent programming you may find it interesting. As we move towards multi-core CPU architectures concurrent programming will become essential in order to make apps scale. Enjoy!
by community-syndication | Jan 16, 2006 | BizTalk Community Blogs via Syndication
I’ve been tracking the CCR internally within Microsoft for a while now, and now there’s an interesting channel 9 interview with the CCR guys: http://channel9.msdn.com/Showpost.aspx?postid=143582 if you’ve ever done any amount of concurrent programming you may find it interesting. As we move towards multi-core CPU architectures concurrent programming will become essential in order to make apps scale. Enjoy!
by community-syndication | Jan 15, 2006 | BizTalk Community Blogs via Syndication
What I am about to describe will not be new to a lot of you, in fact BizTalk Bill suggested this technique a users group meeting. The fact is, that before Christmas I could find no documentation on it in my usual trawling of the blogosphere to see if there was a more elegant way with BizTalk 2004 to employ envelope splitting inside an Orchestration … I couldn’t find one. So I’m going to spell it out for you here.
Before Christmas I was looking into a way of receiving a large amount of data from a retail head office system applying some business process logic on that data as a whole before splitting that data up into individual messages i.e. one message per retail branch. I had quite good control over the validity of the xml from the head office so I was (with aggressive testing) quite sure there wouldn’t be individual records which would fail during validation or transformation. As we were dealing with quite high transaction volumes here I wanted to produce a message for each branch ~400 with as little overhead as possible = Envelope Splitting. The system was likely to be rolled out in BizTalk 2006 soon after go-live so I also wanted to allow for possible easy employment of BizTalk 2006’s really cool recoverable interchange processing and failed message routing functionality.
But hey I’m using BizTalk 2004 and I’m in an orchestration the answer is folks to either:
1. Convince the powers that be to move to BizTalk 2006 (I tried)
2. Write the HO message to disk and then read it off disk through a default xml receive pipeline or your own custom pipeline specifying the envelope schema in an xml disassembler component (better than the default xml receive pipeline for schema versioning) and there you have it individual branch messages.
3. Same as 2 but instead of writing it to disk (you may not want to do this for security, scalability, async processing reasons) write it to an MSMQT queue and then read it off the queue through the receive pipeline which splits the message.
4. See correspondance with Tom Beerley below on how to achieve this using a loopback adapter, thanks Tom!
Hope this helps simple aye
R. Addis
by community-syndication | Jan 14, 2006 | BizTalk Community Blogs via Syndication
I just got the MSDN in the snail mail box and was reading this morning about the new Windows Workflow Foundation (WWF). There is a strong similarity with Biztalk in regards to the Workflow part of BizTalk.
There are some other comments about this comparison. See Darren . Combine this with the news that Scott Woodgate has left the project, I wonder where the BizTalk product is heading to.
Brian Loesgen has published a nice comparison table of BizTalk features v.s. Windows Workflow Foundations.
by community-syndication | Jan 12, 2006 | BizTalk Community Blogs via Syndication
Do you want to join Microsoft? Would you like to help to shape and build the next generation of BizTalk Server? The BizTalk product group is looking for talented individuals to help build the next generation of the product.
If you’re interested or want to find out more about the opportunities email Kerry Van Voris your resume: kerryv@microsoft.com
