-
-
Get the last BizTalk Server documentation update here. As always the online help remains available at MSDN as well.
Together with this core documentation, following updated documents are also available for download:
-
-
Paul Somers (winner of the BTS2004 competition) was so kind to notify me that his BizTalk Admin tool has moved here.
Reading his latest post: the BizTalk Exam certainly tests your BAM skills as well Paul :-)
It looks like we've a lot of good community projects by now and more are coming up. For example: Brian Travis is working on a cool BizTalk Server Message Dashboard; based on my sample project (BizTalk Server Tracking Playground) I made available in June 2004. Hope it will be finished soon as this is cool stuff: his dashboard allows for inspecting tracked messages and context without needing HAT. Even click-through to related messages is supported. More on this as he finishes :-)
-
-
We just released the WSE 2.0 adapter for BizTalk Server! In my opinion this is an important milestone: webservices are increasingly fast becoming the number one interoperable transport both inside and between companies. The need for security, trust and policy is crucial to further extend the wealth of scenario's that webservices enable. I find it an exciting idea to know that Web Services within your business processes now have become just a matter of configuration! Get it here: http://www.microsoft.com/downloads/details.aspx?FamilyId=BA643360-E9DC-4FC5-8D60-8E6C5ECA7861&displaylang=en
-
-
Recently the BizTalk Server exam has been released. Just do as I did and take it to get yourself certified! For more information, see Scott's blog.
Another important milestone in the life of this great product: SP1 has been released TODAY!! Get it NOW!
I strongly advise everyone to test it in your test environment and bring it in production as soon you can: it's worth it! In addition to that, we got now an adapter migration toolkit: something you might find interesting if you're planning to migrate your integration solutions from BizTalk Server 2002 to 2004.
-
-
Due to several reasons (priority shifts...), it's a while ago I blogged here. To eliminate all doubts: I'm still alive and still open to all BizTalk/XML/SOA related questions and discussions :-)
I'm also glad to announce that tomorrow I'll join Microsoft as a product technical presales. It remains to be seen how many spare time I'll have to dedicate to this blog ;-)
Just one more thing I'd like to share here: if you're into the enterprise space and love the integration solutions Microsoft is providing, make sure to check out MIIS (Microsoft Identity Integration Server) as well!
-
-
As appearantly everyone is eagerly looking for a gmail account, I will give away a few more. (At least, my previous blog makes me think that :-))
I'll invite to gmail, the first 5 people who can tell me why I implemented my streaming pipeline component using multiple threads instead of just one :-p.
[Yes, that's right :-) You'll have to read the article on custom pipeline processing for this one :-))))))))))) ]
P.S. Make sure you include your name and current emailaddress in your comment as I need these to invite you.
[Update: I've invited the people who responded. If you don't receive your invitiation, please let me know.]
-
-
Waaw... Finally got my new paper published. Like I already promised a while ago, I was working on a sample and paper, showing how custom pipelinecomponents can be created. Even better: the paper and sample code will show you how to create a *streaming* pipelinecomponent that is able to put data into the msgcontext based upon an XPath expression.
"How's that possible? XPath only works on a DOM Christof - you never can make this streaming!" Yes I can, because of Dare Obasanjo, who recently published a paper and sample code on so called "streaming xpath", which makes up a subset of XPath that can be handled in a streaming, forward-only, way.
For all those funky things: visit the Belgium MSDN site here!
All feedback is welcome, please enjoy this!
-
-
Microsoft just made the results of the BizTalk Server contest public. I immediately started googling but it appears that Paul Somer's entry is not downloadable yet... (Please drop me a line if I'm wrong.) Neverthless, a few cool cool toys appeared on gotdotnet in the mean time. My selection of these:
Please note: I haven't tested nor downloaded all of these. I do not make any judgement on the quality nor availability of the entries above. My only intention here is to give a short overview of what's currently available.
Have fun!
-
-
Todd Sussman posted a few comments/requests on my Transactional .NET Adapter. One of the things I was asked for several times already is whether it would be hard to make it work in a request/response way. Now, to be honest, I did consider this when implementing. A few random thoughts:
- Since the adapter is transactional, and since .NET remoting does not support transactions: the code called by the adapter would always run in process in the same appdomain. (I would need to do really funky things to do this otherwise.)
- I would advice against doing too much work in the component called by the adapter; remember there's a transaction in progress! Ideally the component would access some queue, database or other transactional backend system. Don't start any actions that take a long time and could risk the transaction to time-out.
- Don't start any new threads in your component unless you don't really need the transaction. Any new threads would not retain the transaction context... (Widbey would do a better job here.)
- I decided not to promote request reponse too much since I felt that would raise the risk of blocking the worker thread too long. I was convinced that people needing this functionality would better use another transport to correlate response messages with their request. For example: dropping messages from within your .NET component back on a queue which is asynchronously read by the MQSeries or MSMQ adapter...
Was I wrong? Probably... I'd like to hear all comments you have on this. If you feel you need to have request reponse on the transactional .NET adapter in a scenario, please let me know!
Note to myself: a few other enhancements that I could make:
- load each custom client assembly in a separate appdomain, this would allow for:
- separate security settings for each assembly
- configurable .NET config file for each assembly
- unloading of the appdomain, would prevent needing to restart the BizTalk Service to release an assembly handle
- the request response I just discussed
- provide user with multiple interfaces so they can choose to receive an XmlDocument, XmlReader or just the plain bytestream
-
-
What my last post demonstrated was actually how element reuse limits your ability to reusing an XML Schema definition. Last few weeks I saw still too many people reusing elements over and over without considering what consequences this can have when later on a schema has to be updated, reused or extended...
Regarding the sample, which was correctly identified as invalid by Martijn, Sachin, Peter and Wilco: indeed the XML Schema spec, paragraph 3.3.3 states that "If ref is present, then all of <complexType>, <simpleType>, <key>, <keyref>, <unique>, nillable, default, fixed, form, block and type must be absent, i.e. only minOccurs, maxOccurs, id are allowed in addition to ref, along with <annotation>."
Unless it is very clear that in each and every situation an element will have the same name and exactly the same structure, an element reference is probably not safe to use. I prefer reusing types, wich allow for much more flexible reuse.
Thanks for the comments - you surprised me :-)
Note: I know of a few people already but if anyone else is planning to use the BizTalk Server 2004 Transactional .NET Adapter I've written in a production environment, please get in contact. I'd like to know how this goes, what you plan to use it for and how any additional needs can be further addressed.