Rahul – our National BizTalk Specialist – starts a blog!
Yeah!! You’re the man! Welcome to the blogsphere Rahul! This is awesome. Look forward to your posts… and your expertise here in Australia! Check it out here:
Yeah!! You’re the man! Welcome to the blogsphere Rahul! This is awesome. Look forward to your posts… and your expertise here in Australia! Check it out here:
BizTalk 2006 R2 when installing the EDI/AS2 component (or when re-installing), sometimes
there are some SSIS packages/jobs left that need to be manually deleted
My good mate Rahul has entered the world of
blogging!!! and has blogged about
this very issue and what he did to get around it.
Well done Rahul!!!!
Also I might add upon a reinstall of BTS 2006/R2 sometimes there
are the BAM Alerts notification service instance left over as well –
that typically needs to be manually removed from within the Sql Workbench.
Enjoy
Dependent Drop Downs, Cascading Drop Downs, Filtered Drop Downs. Whatever you want to call them, this is where you have a secondary drop down list filtered based on the choice from the primary drop down list. For example: select a country and you get another drop down list populated with the cities in that country.
This functionality doesn’t seem to be there in WSS 3.0 and/or MOSS 2007. Perhaps I am missing something? (It wouldn’t be the first time) But this seems to be fundamental functionality. Here is some more detail on the scenario:
Country List: I just want a basic drop down list of countries:
City List: I want to filter the cities based on the selected country:
I want a cascading or filtered drop down like so (select Australia, and get a list of Austrlian cities):
Select Germany and get a list of German cities:
Anyway, I couldn’t find a way to do this out of the box, so…I decided to create my own custom field controls to overcome the problem.
I found a couple of useful articles on writing custom field controls. This article describes how to create a custom drop down list user control along with a custom property page:
http://www.kcdholdings.com/blog/?p=56
I used a lot of code from this example, which has a couple of interesting points.First of all it shows how to create a custom Choice field that can be populated from any list on any site on the web farm (not just the current site). It also has an example of a way to get around the problem of saving custom properties of field controls. For some reason this is not as easy as it should be. I think this will be fixed in SP1. This article describes this problem:
http://www.sharepointblogs.com/ aaronrh/archive/2007/05.aspx
Instead of using a delimited string, I used a class to temporarily store the property values. Here is what my property pages look like for the Parent and Child drop down lists:
Anyway, after learning how to overcome the challenges of field controls in general, it was time to move on to the bigger problem of finding a way to create cascading drop downs. I figured there was hope in the “cross list query” or “caml query”:
http://msdn2.microsoft.com/en- us/library/ms467521.aspx
For example, if I want to filter a list of cities based on a country field in that list:
string caml = @“<WHERE>
<EQ>
<FIELDREF Name=”{0}” /><VALUE Type=”Text”>{1}</VALUE>
</EQ></WHERE>;
SPQuery query = new SPQuery();
query.Query = string.Format(caml, “Country”, “Australia”);
SPListItemCollection results = list.GetItems(query);
this.ChildDropDownList.DataSource = results.GetDataTable();
this.ChildDropDownList.DataTextField = “City”;
this.ChildDropDownList.DataValueField = “City”;
this.ChildDropDownList.DataBind();
So I have a parent drop down list that has a SelectedIndexChanged event, that I use to call a method in the child control that binds to the results of the above query.
void ParentDropDownList_SelectedIndexChanged(object sender, EventArgs e)
{
ChildDropDownListFieldControl child = (ChildDropDownListFieldControl)
FindControlRecursive(this.Page, “ChildDropDownList”).Parent.Parent;
child.SetDataSource(ParentDropDownList.SelectedValue);
}
I played around with a lot of different ways to locate the Child drop down list on the page. This is the only one I got to work. (There has to be a better way?)
Anyway, I would appreciate any feedback on any better ways to do this. Here is the source code; I also have a solution file that you can use to install the controls. Just edit the install.bat and point it to the WSS or MOSS site you want to install it on.
The other day I came across a great MSDN article that explains how to do this across
all the BTS Services from SSO through to the rules engine.
http://msdn2.microsoft.com/en-us/library/aa561505.aspx
Jesus
Rodriguez started an interesting discussion here about the differences between WCF
Behaviors and BizTalk Server Pipelines, focused on what the right use cases for
each one are when developing solutions on BizTalk Server 2006 R2 and the WCF adapters
included in it. I think this is a really interesting discussion, and one I’ve given
a bit of thought over the past few weeks. As Jesus correctly points out, this
discussion is also more important because of the changes that might ripple through
the product as WCF and WF permeate the underlying BizTalk architecture as they get
integrated into the core product.
Instead of explicitly talking about Behaviors Vs. Pipelines; I’d like to approach
the topic from a slightly different point of view: the messaging stacks.
In BizTalk 2006 R2, integration between WCF and BizTalk is done by talking advantage
of one of the key extensibility points in BizTalk: The adapter framework. In other
words, both WCF send and receive facilities are exposed to BizTalk (and from BizTalk)
through a set of adapters that hook the WCF model to the BizTalk Messaging Engine
(and ultimately the BizTalk Message Box).
This is obviously a simplification of sorts, but the main idea is that, for this release,
the BizTalk architecture itself didn’t suffer significant changes in order to enable
WCF connectivity. At the same time, WCF didn’t need itself any changes either; though
certainly a number
of extensions needed to be added in order to create fully functional BizTalk our
of the core WCF binding/channels. In many ways, this is a testament of the power and
flexibility of the extensibility models for both platforms. On the other hand,
it means that both messaging stacks are almost fully present, with all the differences
and similarities they have.
What will future versions of WCF/BizTalk look like? I honestly don’t know, but one
can speculate a bit. An interesting thing that might give us some clues about what
is to come is to examine some interesting differences between the two models. While
there are many similarities, there are also some key aspects where WCF approaches
things differently from BizTalk. Here are a few:
Messages
A lot of people mistakenly think that BizTalk Server is all about XML messages and
that anything flowing through BizTalk must be XML. While it is true that XML messages
are first class citizen in BizTalk and that many aspects are modeled around XML-like
concepts, this isn’t really true.
In particular, at the messaging level, when you’re working with Adapters and Pipelines,
messages are simply streams of bytes. What those bytes contain is really irrelevant
to BizTalk; all it cares is that it can read and manipulate those streams. In fact;
it’s pretty easy at this layer to deal with purely obscure or binary data; though
obviously some components will make assumptions about what the data should look like
(example: the Xml Disassembler expects to be able to interpret the message stream
as XML text).
In WCF, on the other hand, the message concept is more closely tied to XML; however,
not to the textual XML representation, but rather to the XML InfoSet. This means that
it is still perfectly possible to deal with other kinds of data as long as there’s
a component in the WCF stack that can make it look like an XML Infoset. This can be
done either by actually translating from another representation into XML (say a database
structure to XML) or by “faking it” (such as a binary stream with fake open/close
XML tags).
In practical terms it means that, for the most part, you can accomplish the same thing
in both models; though it does mean some things get done at different layers in the
stack. For example, in BizTalk, interpreting message content is usually done fairly
up in the stack (i.e. the pipeline, unless you have an application adapter with specific
needs), meaning things like message format are only looked into until fairly late
in the game. In WCF, however, these tasks are usually done very early own, usually
at the request of the Transport Channel.
This does not mean that the transport channel author has to necessarily need to implement
things like message parsing, but it may mean that it is his/her responsibility to
ensure it gets done. For example, a transport channel will call the configured MessageEncoder
to encode/decode messages into/from the network.
Message Structure
Another interesting aspects is message structure. In BizTalk Server, messages are
not really a single entity. Instead, each message is composed of one or more “message
parts”, each one containing it’s own data stream independent of the rest, with one
of them being marked as the “body” of the message. Also, each message carries around
a property bag [1] associated to it (the Message Context), which can be used
to carry “out-of-band” data. and that is a critical part of BizTalk’s Pub/Sub
mechanism.
WCF messages aren’t quite structured the same way. In fact, WCF messages don’t quite
have the concept of “multi-part messages” as clear as the one in BizTalk Server (though
support for protocols like MTOM certainly make it possible) and so only really have
a single, body data stream (or really, Xml feed) associated with them. However, unlike
BizTalk, they also have two different ways to carry out of band data: Message
Headers (obvious, if you consider that the WCF model is closely tied to SOAP), and
Message Properties.
Assembling and Disassembling
Another interesting difference between BizTalk and WCF, and that Jesus already pointed
to, is the fact that, in WCF, interchanges are really one-to-one throughout the WCF
stack. That is, one message comes in, one message comes out.
This is rather different from BizTalk, in which the assembling and disassembling stages of
send and receive pipelines respectively were created explicitly with the idea
that messages might be joined or split during processing. This is why the stages are
referred to using the terms assemble/disassemble and not simply as “parsing” or “translating”.
On the receive side, this enables some really powerful mechanics for processing large
interchanges, by breaking (debatching) messages as they come in into smaller
parts that can be processed individually. Similarly, on the send side, multiple messages
can be joined into a single, larger message. Unfortunately, the latter functionality
is never used by the messaging engine (though it is accessible when calling pipelines
directly from orchestrations).
So this is one point where there’s a significant difference between the two messaging
models. Certainly, nothing would prevent a WCF transport channel from implementing
it’s own disassembling/assembling functionality, though it might be a complex job,
and likely not very reusable. It might be possible to implement it at higher levels
of the channel stack as well, but I really haven’t looked too closely into this, as,
in general, this isn’t as useful a feature in the context WCF services are normally
used (but it is a very important one in the context BizTalk is used).
Channel Shapes
BizTalk Server only really has two different Message Exchange Patterns: Either you
support exchanging messages in a single direction (one-way) or in both directions
(two-way).
WCF, however, supports 3
different message exchange patterns (you could say the third one can also be simulated
in BizTalk). The key differentiating here, however, is that WCF creates, on top of
these three basic MEPs, a large number of different Channel Shapes, which
complement the basic interactions by separating stateless and state-aware variants.
Thus, the appearance of Session-aware channels.
It’s obvious that WCF’s model is here quite a bit more powerful than what BizTalk
offers right out of the box, though it can be argued as well that this makes the model
a lot more complex (and more confusing) for channel authors. BizTalk essentially assumes
that all interactions are stateless (i.e. the concept of session doesn’t exist); which
is partially mitigated by the powerful orchestration + correlation sets combo.
I think it will be extremely interesting to see how the concept of sessions is brought
into the main BizTalk architecture in a future version as WCF gets integrated more
deeply with the BizTalk messaging engine. It certainly adds a few new challenges to
the decoupled, highly asynchronous interaction model between BizTalk components.
Conclusion
I don’t really know what the future will bring for these two platforms, but certainly
the combination of WCF + WF + BizTalk is going to bring significant changes to the
platform. I have a few gut-feelings about what it may look like, but they don’t even
qualify as educated guesses .
Still, it’s going to be pretty interesting to see how it evolves.
[1] There’s also a property bag associated with each message
part; but it is used less often and isn’t as important as the message context.
If you joined me for the two presentations I did Wednesday here in Minneapolis, then you’ll find the code downloads for those sessions here(WCF/WF) and here (SharePoint and WF). If you weren’t there, then never mind.
I usually despise blogs that do nothing but link to other posts (breaking rule #11 in Jeff’s list of blog clich%u00e9s), but, there were a few BizTalk/service things that caught my eye this week and I thought I’d briefly point them out.
Yossi Dahan inspects my recent write up on BizTalk and static objects and makes […]
It has been awhile since I last blogged. I have been away working on a very interesting project for a financial services company. The project entailed building a service broker using BizTalk 2006 (not R2) with WCF to achieve better decoupling of service consumers and service providers….(read more)
The launch has been set and I couldn’t have it better as the BizTalk World Wide launch
is based in Sydney!!! Cool.
The Event is Free and would be a great chance for you to come on
down and talk to members from the BizTalk Product Group that are
flying over.
We’ll all be there and looking forward to the event.
Remember that an upgrade path exists from 2004, 2006 and 2006 R2 B2 to the release
of BTS.
Register here – R2
Event
We’ve got a bunch of R2 sessions all lined up.
8.45am – 9.15am |
Registration |
9.15am – 9.30am |
Welcome and Opening Remarks |
9.30am -10.10am |
KEYNOTE – Six technology trends that will shape the next decade
The question that all IT organizations need to answer is – how can we utilise our |
10.10am – 10.40am |
Break |
10.40am – 12.00 noon |
Extending the Connected Enterprise
Every day, high-performing companies connect their internal departments, their support |
12.00pm – 1.00pm |
Lunch |
TRACKS |
Healthcare/Public Sector |
Supply Chain |
Financial Services |
1.00pm – 2.15pm |
Health Information Networks – the Health Connect Engine
Many countries around the world are tackling the issues of providing better care, |
The World is Flat: Using Technology to achieve and maintain supply chain advantage
As the face of the global economy continues to change, companies are under increasing
|
SWIFTNet Funds & Payments using the BizTalk SWIFT Accelerator
This session demonstrates the BizTalk SWIFT Accelerator to provide the most comprehensive, |
2.15pm – 3.25pm |
Shared Services between Government agencies using BizTalk
Federal and State governments are all working towards improving outcomes, value and |
Orchestrating the real-time enterprise from plant to business with BizTalk
Ready to unleash the potential of RFID information and enable a new class of solutions |
Integration-centric implementation of BPM in Financial Services
With the inclusion of BizTalk in the Microsoft BPM stack it is now possible to integrate |
3.25pm – 3.55pm |
Break |
||
3.55pm – 5.10pm |
The Microsoft Customer Care Framework – an integrated customer service desktop
The Microsoft Customer Care Framework (CCF) provides a single view of the numerous |
Managing high volume transactions using B2B in the manufacturing and retail
In our increasingly federated world, businesses rely on partners and supply chains |
ASB – One Step Ahead with BizTalk Server R2
ASB has a long history of innovation. As one of New Zealand’s leading financial services |
Keeping the Lights On: Managing mission critical processes in Australia’s
The de-regulation of global energy markets has given consumers and businesses freedom |
|||
5.10pm – 6.10pm |
Launch Reception Drinks |
Back to Main
page