by community-syndication | Oct 13, 2005 | BizTalk Community Blogs via Syndication
I had the pleasure of delivering a short talk at the Business
Process Integration & Workflow Conference last week in Redmond. The
whole conference was great, especially meeting quite a few folks in person I’d only
conversed with via email. Being notified of MVP status for BizTalk on Friday
was a great cap to the week!
Although the sample I presented during my talk isn’t quite ready to release, the slides (on
scatter/gather scenarios in BizTalk) can be downloaded here.
by community-syndication | Oct 13, 2005 | BizTalk Community Blogs via Syndication
I had the pleasure of delivering a short talk at the Business
Process Integration & Workflow Conference last week in Redmond. The
whole conference was great, especially meeting quite a few folks in person I’d only
conversed with via email. Being notified of MVP status for BizTalk on Friday
was a great cap to the week!
Although the sample I presented during my talk isn’t quite ready to release, the slides (on
scatter/gather scenarios in BizTalk) can be downloaded here.
by community-syndication | Oct 13, 2005 | BizTalk Community Blogs via Syndication
Is it KFC or Kentucky Fried Chicken? Well in that case legally it doesn’t matter because the same company owns both the name and the abbreviation. Of course for marketing reasons they have swapped from the full-name to the abbreviation and back but that’s another story.
In the case of Windows Workflow Foundation we own the name Windows Workflow Foundation. However, we didn’t trademark an abbreviation so there is no official abbreviation. Indeed we tried, albeit with a phenomenal lack of success, to launch the technology referring to its name and its name only. It was an interesting study in Microsoft and press culture to see people abbreviating to WWF with a few notable exceptions here and here. Given people’s natural desire to abbreviate the technology name to three letters and potential, untested, issues with the WWF acronym we feel compelled to strongly suggest you use the acronym “WF” for the technology only.
Remember its Kentucky Fried Chicken (Windows Workflow Foundation) not KFC (WF) so use WF when you are severely space constrained.
by community-syndication | Oct 12, 2005 | BizTalk Community Blogs via Syndication
You can find my thoughts on a really simple message replay (message
re-processing) technique for BizTalk in Stephen Thomas’ The BizTalker newsletter.
Check it out here.
For additional clarification, I’ve created a quick Visio here.
by community-syndication | Oct 12, 2005 | BizTalk Community Blogs via Syndication
You can find my thoughts on a really simple message replay (message
re-processing) technique for BizTalk in Stephen Thomas’ The BizTalker newsletter.
Check it out here.
For additional clarification, I’ve created a quick Visio here.
by community-syndication | Oct 11, 2005 | BizTalk Community Blogs via Syndication
The is the fifth of five entries talking about schema design patterns. After looking at each of these schema design patterns now we can look at how we can use these design patterns in the BizTalk Editor. So, lets create reusable structures. Open the editor by creating a new schema. When the schema appears in the Editor you get a Schema node and the Root Node. What we will do is to create our schema under the Root Node and then we add our global types at the same level as the Root Node.
So, lets create a global record, a global element and a global attribute – just to make sure we have all of our bases covered. Once these have been created then I will show you how we can use those within our schema.
Before we create these global items we need to keep in mind that you can create global types using records, elements or attributes. However, types created from elements can only be used in elements, records can only be used in records and attributes can only be used in attributes. This is especially important to keep in mind when importing a schema for reuse since you will need to know the types that are available for reuse since they will only be selectable for similar types.
First, lets create a global type. Create a record named Employee directly below the Schema node. Below the Employee record add three elements; EmployeeID, FirstName and LastName. Click on the Employee node and in the properties window, select the Data Structure Type and enter EmployeeType. This will be the name of the complex type that will be used when reusing this type.
Second, lets create a global element. Create an element named Company and place this directly below the Schema node as well. With elements and attributes you do not need to name it as you do with a Record (there is no Data Structure Type property on elements or attributes).
Third, lets create a global attribute. Create an attribute named EmployeeType directly below the Schema Node. Click the Derived By drop down in the properties window and select Restriction. This will expand the properties to include a Restriction Section. Set the Maximum Length to 1.
We have now created all of our reusable types, so now lets use them.
To begin with we will use our global element. Click on the Root node that was created with the Schema and add a Child Field Element. Click the Data Type drop down and in the list there will be an entry that says “Company (Reference)” – Select this value. We have now linked this element with the global element. Also, notice that the name of the element has changed to match the name of the global element.
Next, we will use our global records. Lets add two child records. The first will be named FTE and the second will be named Consultant. Lets start with the FTE record. Select the Data Structure Type drop down in the properties window and select EmployeeType (ComplexType). Repeat the same process for the Consultant Record. We now have two records re-using a the same global type.
Lastly, lets use the other global items that we created earlier to decorate the FTE record. The process is the same for attributes and elements. So on the FTE record add an attribute by right clicking on the FTE Record and selecting Child Field Attribute.
Once the attribute has been added, click the Data Type drop down in the properties window. At the bottom there will be an entry that says “EmployeeType(Reference)” – Select this value. We have now linked this attribute with the global attribute. Again, notice that the name of the attribute has changed to match the name of the global type. Here is a screen shot of what it looks like so far.
There is one last thing to look at while we are working on our attribute. You may have noticed that the properties for this attribute are read only. By changing the properties on the global definition we can affect the properties of the items that use these types. When we created the global attribute we selected Restriction and set the Maximum Length to 1. Change this value (or any other) and you will see the change flow through to be reflected in the attribute that points back to the global attribute.
What it really comes down to is that there are two different ways to select global types depending on what the type is. If the type is a record then select the globally defined type from the Data Structure Type property. If the type is a element or attribute then select the globally defined type from the Data Type property. Keep in mind that once the global type has been assigned then any changes to the globally defined type will appear in any of the locations in which the global type has been used.
So, now that you have seen the process all that you need to do is to follow any of the patterns described earlier in this series and create the schema you want..
There is one last gotcha to be aware of. If you are importing a schema in order to use global types defined in another schema file and there are promoted properties defined on any of the global types you will need to re-promote them in your schema for the promoted properties to take effect.
by community-syndication | Oct 11, 2005 | BizTalk Community Blogs via Syndication
In talking with others, it appears that the NAnt vs. MSI deployment camps are pretty much split down the middle. I tend to lean towards MSI deployments for several reasons.
When dealing with MSI packages, it is often necessary to go beyond the somewhat basic BTSInstaller project that comes with BizTalk. I have posted before on custom actions to fill in the gaps that come with using the BTSInstaller. Another thing to think about when using MSI deployment is what happens if BizTalk is not installed to the default install directory (it’s very common for enterprise clients to install software to a drive other than C:\). If you are deploying pipeline components, this is important as they have to be copied to the Pipeline Components directory of the BTS install directory. Another thing to keep in mind is if you create custom adapters. The tricky part with custom adapters is that they require registry settings. You can include a reg file for the installer to run, but it would be nicer to handle that for them. Additionally, one of those registry settings is the path to the custom adapter component. Again, you can’t be sure of the install directory of your components.
Luckily, it’s pretty easy to handle both of this situations following the steps below –
Determining the BizTalk install directory
This one turns out to be pretty easy as the BTS install directory gets stored in the registry. And, the MSI install project gives us the ability to search the registry, so we just need to know what to search for.
- In the install project, right click and choose View|Launch Conditions.
- Name the launch condition BizTalk Install Path.
- Enter BIZTALKINSTALLPATH for the Property property. We will use this property later.
- For the RegKey property, enter SOFTWARE\Microsoft\BizTalk Server\3.0.
- For the Root property, choose vsdrrHKLM from the dropdown.
- For the Value property, enter InstallPath.
Now that we have set up a launch condition to find the BizTalk install path, we can make use of that value in our install process. For pipeline components, I like to add a new folder to the File System section of the install project and name it Pipeline Components. In the DefaultLocation property of that folder, enter [BIZTALKINSTALLPATH]\Pipeline Components as the value. You will notice [BIZTALKINSTALLPATH] is how we get to our properties of the install project. It’s that easy.
Determining install path chosen during install process
For this section, I’m going to leave out most of the steps you need to take to add the registry settings to register your custom adapters. Contact me if you need that information. The easiest way to handle this is to run the wizard that creates the .reg file for you (you can find this tool on the web), and make sure you add all those keys in the Registry section of the install project.
Two properties to take particular note in are the AdapterMgmtAssemblyPath and the InboundAssemblyPath. These properties point to specific paths of your components (generally the same component). So, we need to somehow capture where the installer has chosen to install our components, and then make use of this value.
- Right click on the installer project, and choose View|File System.
- Select the Application Folder folder on the left side. Notice that the property (which is read only in this section) is set to TARGETDIR. This is similar to our BIZTALKINSTALLPATH property that we created.
- Right click on the installer project, and choose View|Registry. This is where you will enter all the keys and values you need for your custom adapters. When you get to the AdapterMgmtAssemblyPath and the InboundAssemblyPath properties, you will prepend you assembly name with [TARGETDIR] and enter that for the value of the key.
Remember, when creating install packages, we want to make the install process as “painless” for the installer as possible. These folks are typically not BizTalk people, and even worse, the process is usually automated. Hopefully these little tips will make your MSI package creation a little easier.
Cheers,
Todd
by community-syndication | Oct 10, 2005 | BizTalk Community Blogs via Syndication
Oliver Rist wrote a column in his blog titled “
What about BizTalk?” Historically I haven’t responded to these types of articles, but that’s what blogging is supposed to be for – expressing your opinions and this seemed like a good article to respond to so here we are. Starting at the beginning – I never really like the Michael Vaughan character on Alias. He kind of reminded of a secret agent for a certain European country and a Greenpeace incident in NZ a while back so I was happy to see him being written out of the script (assuming he doesn’t reincarnate).
Oliver asserts that for the vast majority of its implementations BizTalk will require plenty of time and money. When I started in this business 5 years ago integration products were sold by sales folks who owned boats, fancy cars and the type of houses with those cute Victorian layouts and views of large lakes. Why? The software was super duper expensive. Microsoft has been singularly responsible for reducing the price-point of integration software by over 100 times. Indeed we are still the price-leader in the space and in several deals that come to mind our competitors have dropped their catalog prices by 40% just to be within the realm of our pricing when they hear that the competitor is BizTalk Server. On the other hand, Oliver does have a point hooking up existing systems across multiple platforms is inherently a tricky proposition and for that reason BizTalk developers get paid more than Web developers and the projects tend to be more strategic to the very existence of enterprises.
Oliver talks about BizTalk Server being revved back – I’m not sure why. BizTalk Server is not being revved back in the slightest way – that won’t make sense as the business is doing very well. Indeed we have shipped more innovation more frequently than any other server product from Microsoft in the last 5 years, with 4 new versions, and that will continue. We now have 5000 customers making us the #1 in our space in terms of customers and we are growing strongly as a business due to the value that our customers find in our product. We are currently planning BizTalk Server vNext which will include Windows Communication Foundation, Windows Workflow Foundation and lots of specific BizTalk innovations.
According to Oliver BizTalk is a proprietary platform which costs money. I guess I could argue this both ways. One way would be to define the term proprietary. If he means that it isn’t open-source and it is a for cost product then that’s absolutely true and is equally applicable to IBM Web Sphere, SAP, Oracle and all the players in the integration and business process space. Another might be that it is somehow closed in the sense that it only supports “Microsoft stuff”. BizTalk Server provides the largest level of interop of any Microsoft product to numerous platforms and recently we acquired 9 adapters to help our customers broaden that through connectivity to Oracle, Siebel, TIBCO and so on..
So what about BizTalk and Windows Workflow Foundation? Did you bet on the wrong horse by choosing BizTalk Server? No you didn’t. BizTalk Server is, was, and will be the right architecture for business process and integration on Windows. To properly serve the needs of business process and integration you need a “man in the middle” server that adapts, routes, tracks, manages, scales and has all the appropriate BPM capabilities such as BAM. Windows Workflow Foundation gives you none of that. On the other hand there are many scenarios that Windows Workflow Foundation is useful outside of business process and integration such include page-flow in ASP.NET web applications, workflow within line of business applications that ISVs build, workflow within Office. By targeting ISVs primarily the Windows Workflow Foundation technology can be embedded within these applications.
Put simply:
A. Workflow within applications = Windows Workflow Foundation
B. Workflow across applications = BizTalk Server
I love working with the press, but on one or two occasions some “selective editing” has provided some out of context quotes. Let me reverse the situation and end on my favorite part of Oliver’s article “In fact, the synergy of [Windows Workflow Foundation] and BizTalk will probably make you look like a visionary”. You bet we are working hard to make that 100% a reality.
by community-syndication | Oct 9, 2005 | BizTalk Community Blogs via Syndication
In Microsoft’s Windows Workflow Foundation (WF), rules are executed through a sequential, rather than an ‘inferencing’ engine. Although WF rule processing bears a superficial resemblance to rule processing in the Microsoft Business Rules Engine (MS BRE), there are profound differences. This article attempts to explain the fundamental differences, and to provide some insight into the strengths and weaknesses of each approach.
by community-syndication | Oct 5, 2005 | BizTalk Community Blogs via Syndication
SSO -> RPC server is unavailable.
I had problems with the Single Sign On (SSO) to get authentication to execute a SOAP request (or so I thought)
In one of my actions of trying to resolve it, I tried to reset the SSO server name to the machine name. This is something I absolutely should not have done!
C:\Program Files\Common Files\Enterprise Single Sign-On>ssomanage.exe -serverall Namgang
C:\Program Files\Common Files\Enterprise Single Sign-On>ssomanage.exe -server Namgang
This did result in the error “The RPC server is unavailable” for almost all of the ssomanage.exe and ssoconfig.exe commands:
C:\Program Files\Common Files\Enterprise Single Sign-On>ssomanage.exe -displaydb
Using SSO server : sso
SQL Server : namgang
SSO database : ssodb
ERROR: 0x800706BA : The RPC server is unavailable.
The google searches on “RPC server is unavailable” and “BizTalk” or “SSO” did not give me any clue what kind of trouble I just created. So here is my little contribution for others:
I thought the SSO server name would be my machine name, but after hours (almost days) I found out that the original sso server name was not my machine name, but the IP address!
I found this by running the rpcdump.exe utility. After resetting the SSO server name to the IP address for -serverall and -server, I had it up and running again.
C:\Program Files\Common Files\Enterprise Single Sign-On>ssomanage.exe -server 192.168.1.101
The operation completed successfully.
C:\Program Files\Common Files\Enterprise Single Sign-On>ssomanage.exe -serverall 192.168.1.101
The operation completed successfully.
C:\Program Files\Common Files\Enterprise Single Sign-On>ssomanage.exe -displaydb
Using SSO server : 192.168.1.101
SQL Server : namgang
SSO database : ssodb
SSO secret server name : NAMGANG
SSO Admin account name : SSO Administrators
SSO Affiliate Admin account name : SSO Affiliate Administrators
Size of audit table for deleted applications : 1000
Size of audit table for deleted mappings : 1000
Size of audit table for external credential lookups : 1000
Ticket timeout (in minutes) : 2
Credential cache timeout (in minutes) : 60
SSO status : Enabled
Tickets allowed : No
Validate tickets : Yes
Sent the rpddump.exe to a output.txt file, and you can examine the dump with notepad.
C:\Program Files\Resource Kit>rpcdump.exe /V > output.txt
Or look specific at an IP address and notice the SSO servers
C:\Program Files\Resource Kit>rpcdump.exe /s 192.168.1.101
Querying Endpoint Mapper Database...
78 registered endpoints found.
ncacn_ip_tcp(Connection-oriented TCP/IP)
192.168.1.101[1030] [1b6a54d8-0f2a-47b2-b934-e876b711eb19] SSOSecretServer :NOT_PINGED
192.168.1.101[1030] [87632da4-2f1c-4e92-953a-41306b36c095] SSOCSServer :NOT_PINGED
192.168.1.101[1030] [87a18bff-b7a4-4d79-a996-b9811cd73c94] SSOLookupServer :NOT_PINGED
192.168.1.101[1030] [416767be-be19-433e-91c3-4ad2ed88dede] SSOAdminServer :NOT_PINGED
192.168.1.101[1030] [906b0ce0-c70b-1067-b317-00dd010662da] :NOT_PINGED
192.168.1.101[1030] [fe1bcf2e-700c-47ca-b47b-7d1c8688307f] SSOMappingServer :NOT_PINGED
192.168.1.101[1025] [82ad4280-036b-11cf-972c-00aa006887b0] :NOT_PINGED
[deleted]
rpcdump.exe completed sucessfully after 1 seconds
