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!
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!
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
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.
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: [email protected]
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: [email protected]
I am interested in anyone’s experience with writing a transactional adapter using the base adapter as a foundation. More specifically anyone who has used the Pathfinder sample transactional adapter as a basis for development. Comments?
We are currently experiencing a bit of pain at my current client trying to configure BizTalk 2006 in a multiserver environment. The Active Directory configuration that this installation must adhere to consists of two forests. One of these contains all the production accounts, the other which is trusted by the first. Accounts from the domain in the first forest are put into domain local groups in the second.
This has all worked fine in our BizTalk 2004 installations, we have never experienced issues related to this set-up. However, while attempting to run through the configuration in BizTalk 2006 there have been numerous issues when defining the account to use for the Windows Service and/or the group assigned against the BizTalk role. The error messages have been similar to the following:
Error: Failed to add the user ‘DOMAIN1\INSTALL_USER to the domain group ‘DOMAIN2\SSO_ADMINISTRATORS_GROUP’. To add members to domain groups you must have sufficient permissions in the domain (SSO)
Additional Information:- 0x000008AC The group name could not be found
Where:
Now, the error would lead you to believe that either the account or group doesn’t exist, or that the account isn’t a member of the group. However this is not the case and there is ongoing dialog between us and Microsoft as to what is the cause of the issue. It seems there have been problems realting to cross domain local group Active Directory configurations and I will be posting a follow-up when a solution or workaround has been found. This is just a heads up that if you are going to be using such a configuration, be wanred that you may obtain a headache rather quickly.
We did manage to get past the checking that occurs during the Enterprise SSO configuration by entering a debug registry key entry that will turn the Error you get in this scenario into a Warning. Errors stop you from continuing with any further configuration steps, whereas a warning will not. This is achieved by entering the following:
Although this allowed us to progress, it didn’t allow us to complete the configuration as a similar issue occurs when you enter the BizTalk Runtime configuration. Another check occurs here between the accounts and groups you enter, and as they are also using the same AD configuration as the SSO account and group the same problem arises.
As I said, I will keep you posted on the outcome of this and as usual note that this has been experienced with beta 2 of the product and may not be an issue in later releases.
We are currently experiencing a bit of pain at my current client trying to configure BizTalk 2006 in a multiserver environment. The Active Directory configuration that this installation must adhere to consists of two forests. One of these contains all the production accounts, the other which is trusted by the first. Accounts from the domain in the first forest are put into domain local groups in the second.
This has all worked fine in our BizTalk 2004 installations, we have never experienced issues related to this set-up. However, while attempting to run through the configuration in BizTalk 2006 there have been numerous issues when defining the account to use for the Windows Service and/or the group assigned against the BizTalk role. The error messages have been similar to the following:
Error: Failed to add the user ‘DOMAIN1\INSTALL_USER to the domain group ‘DOMAIN2\SSO_ADMINISTRATORS_GROUP’. To add members to domain groups you must have sufficient permissions in the domain (SSO)
Additional Information:- 0x000008AC The group name could not be found
Where:
Now, the error would lead you to believe that either the account or group doesn’t exist, or that the account isn’t a member of the group. However this is not the case and there is ongoing dialog between us and Microsoft as to what is the cause of the issue. It seems there have been problems realting to cross domain local group Active Directory configurations and I will be posting a follow-up when a solution or workaround has been found. This is just a heads up that if you are going to be using such a configuration, be wanred that you may obtain a headache rather quickly.
We did manage to get past the checking that occurs during the Enterprise SSO configuration by entering a debug registry key entry that will turn the Error you get in this scenario into a Warning. Errors stop you from continuing with any further configuration steps, whereas a warning will not. This is achieved by entering the following:
Although this allowed us to progress, it didn’t allow us to complete the configuration as a similar issue occurs when you enter the BizTalk Runtime configuration. Another check occurs here between the accounts and groups you enter, and as they are also using the same AD configuration as the SSO account and group the same problem arises.
As I said, I will keep you posted on the outcome of this and as usual note that this has been experienced with beta 2 of the product and may not be an issue in later releases.
Randal van Splunteren published a handy little utility over on the BizTalk Intelligence Agency blog this morning – the BizTalk Host Manager. Turns out I had a similar utility under way, but he already has the icon done, so what the heck – I’ll just use his instead!
Hey Randal – one […]