Release Date : November 2012
After I completed their 2006 R2 / ESB implementation, the client had cloned the ESB 1.0 and deployed it on web servers. Not only did they duplicate the Itinerary functionality, but they customized it. They created their own custom core components and pipeline components.
I won’t go into the details (saving these for the Anti-Pattern List). One of my tasks was to help the developers migrate their custom ESB Web Application to ESB 2.1. All their tests were failing. I was expected to help their developers.
A good source that describes the BizTalk Architect Role can be found on the TechNet Wiki.http://social.technet.microsoft.com/wiki/contents/articles/6243.biztalk-roles.aspx#BizTalk_Architect
If you search the TechNet Wiki http://social.technet.microsoft.com/wiki/, you should be able to details on other roles.
I had ordered this book several months ago and just received my copy yesterday. I hadn’t had a chance to read the book in depth. Normally I look at the table of contents and just read the chapters that interest me. I found this book a little different; all the chapters included sections that sparked my interest.
The author, Steef-Jan Wiggers is considered to be one of the top BizTalk experts in the world. He is well known and widely respected for his contributions to the BizTalk Community. He is a MVP for BizTalk, a distinction not easily earned.
Unlike most cookbooks, in which the chapters do not follow a pattern, I found that the recipes read much like tutorials. Steef-Jan has included sample code for each chapter.
Once I have time to thoroughly read the book and work through some of the samples, I will continue this review. From what I have seen so far, this book is a “must buy” for anyone involved with BizTalk. As I mentioned previously, this book is not only geared for BizTalk Developers.
 |
Start designing your ESB Itineraries first |
| The client had decided that they needed an ESB to send data from SharePoint to a Data Repository. I don’t believe that they fully understood the capabilities of BizTalk 2010 and how the ESB Toolkit 2.1 is used. Apparently they had no actual experience in architecting and designing BizTalk / ESB Solutions. They did have quite a bit of experience and knowledge in architecting .NET Applications and WCF Services. Having read all about the use of Itineraries in the ESB Toolkit 2.1, it was decided that their newly trained and inexperienced Lead BizTalk Developer would develop a framework of Itineraries for routing messages, that could be reused. The inexperienced developer simply took the samples included with the ESB Toolkit and “adapted” them. The developer was told that Itineraries would be designed first. At this time they had no requirements for BizTalk Applications. To add fuel to the fire, it was dictated that they would use SCRUM for all projects. The BizTalk Developers would develop their Itineraries in multiple sprints. Notice that there has been no reference to designing BizTalk Applications. |
Using the Generated Operations Name for the Action (SOAP Action Header)from a WCF LOB Adapter |
| A BizTalk developer was using the WCF LOB SDK to generate a WCF LOB SQL Adapter service to perform several CRUD Operation on database tables. The developer built the application, deployed it, and imported the generated bindings. The section showing the Operations is shown below. |
 |
| The Bindings for the SOAP Action header is shown below. |
 |
| The developer needed to create an Orchestration to consume the service. He created a new BizTalk Project with an Orchestration. The Orchestration was to be used to Insert data into two tables He then added a new Request/Response Port with two operations as shown below. |
   |
| If you compare the difference between the WCF LOB Service Operations names and what the developer used for the Port Operations Names you will notice that they do not match. After deploying the Orchestration the developer, he then tried to test it. An Insert Request Message was sent to the WCF Service. He did not receive an Response Message. After checking the Applications Event Log, he discovered that he had an invalid type error. He came to me for help and we discovered he had misnamed the Operations on the WCFLOBPort in his Orchestration. The issue here is that both the Operations Name in the Bindings and the Operations Name for the Orchestration Port must be the named the same. Recommendation: |
Naming your Port Operations so you can easily identify them in theOrchestration is a good practice. You will need to modify the OperationName for the Action on your port to match. to identify, especially when you could have multiple Select, Insert, Update,and Delete Operations within an Orchestration. |
Using ADO.Net instead of SQL Stored Procedures for CUD Operations |
| A client wanted to promote the reuse of WCF LOB SQL Adapter services. It was decided that they would use |
There was a requirement to: |
|
| They wanted to handle this within an Orchestration. I told them that they needed to validate each operation within a Scope and if any operation after the initial Insert failed, they would need to use the Delete Operations for Compensation. |
| I suggested a better way to handle it was to create a Stored Procedure with a Transaction to handle all the |
| They didn’t like the idea of putting this “business logic” in a Stored Procedure. It didn’t fall in with their overall |
| Their Architect decided that using ADO.Net classes was a better way to solve the problem. They could call these |
Spending the entire budget for BizTalk Development and leaving nothing |
| A former client decided that they wanted to use BizTalk 2010 for their Messaging Solution. |
| At first, they had planned on training five developers. Someone came up with the idea that |
Can you imagine what the cost was for several weeks of training…? |
| Prior to my starting with the client, they had migrated several HL7 feeds from their legacy system to BizTalk. |
| Their BizTalk Administrator had done an excellent job of installing and configuring their production environment. |
| They had sent their BizTalk Administrator for a week of training. It was my job to continue his training and guide him on the administration and operations tasks necessary for an enterprise BizTalk 2010 infrastructure |
| I recommended that they implement SCOM 2007 R2 or another third-party tool to monitor their BizTalk infrastructure. We were told us that they ran out of budget money |
| I suggested that they create a VM, so the BizTalk Admins could learn how to use SCOM and to |
| It seems that all the architects and developers were provided with a VM and they did not have the |
To be continued… |
TWOCONNECT has updated the open source ODBC Adapter made on GotDotNet several years ago, to work with BizTalk 2010. It has been updated to support the Net 4.0 Target and the Install Folder Path has been fixed for 64 Bit Systems.
According to TWOCONNECT:
For the scenarios, we are going to use SQL 2008 R2 Server Database as our ODBC Source.
Before we can use the Adapter we need to install it.
Installation is fairly straight forward
We will have to manually add the Adapter to our BizTalk Environment as shown below:
We start off with creating a new 32 Bit Host and Host Instance as shown below:
We then assign our ODBC Host Instance to the ODBC Adapter’s Send and Receive Handlers as shown below.
Assign our ODBCHost to Send Handler
Assign ODBCHost to Receive Handler
Assuming that our BizTalk 2010 Environment is 64 bit, we will need to use the odbccad32.exe, which is located in C:\Windows\SysWOW32, to create your ODBC Data Source.
We create a new System Data Source as shown below
Clicking “Add” starts the Configuration Wizard.
Enter a name for our Data Source.
Select our SQL Server.
Click “Next” until you get to the page show below.
Check the “Change the default database to:” and select our PurchaseOrders Database.
Click “Next” again.
We can review our configuration as shown below.
Click on “Test Data Source” to test our connection as shown below.
If we configured everything correctly, we will see the results as show above.
Open Visual Studio 2010 and create a new BizTalk Application. Name it “ODBC_Sample”.
1. Next we will use the “Add Adapter Metadata Wizard” to generate our schemas and orchestration as shown below.
2. Select the ODBC Adapter as shown below:
3. Click “Next”.
4. Then enter our Target Namespace, Request and Response element root names as shown below.
5. Click “Next”.
6. We will be doing a simple Select Statement. Select “SQL Script” and click “Next” as shown below
7. On the Statement Information page, we set the “Query Type” to Select.
8. Next we will enter our Select Statement as shown below.
9. Next Click “Generate”.
After a few seconds you will see two schemas and an orchestration in your project folder.
10. Since we did a Select without a where clause, our generated schema is generic as shown below.
11. The Response Schema contains all the fields from our table.
12. Looking at the Multipart Message Types, we can see that there is a problem with the Multi-part Message Types. (This is one of the issues in the Adapter)
13. To correct this, we will need to re-assign the schemas to the Message Type.
14. Another issue is that there are two ports created instead of one as shown below.(This is also an issue with the adapter).
15. The solution to this issue is to delete the ODBCRequest and ODBCResponse Port Types and create a new Request-Response Port as shown below.
16. Next we need to add our Inbound Message. We are using the Request Message generated by the Adapter Wizard.
17. The following is our Port Binding.
18. The completed Orchestration for our first demo is shown below.
We will need to repeat Steps 1 – 5 .
6. In order to do an Update, we need to manually enter our Update Query into the Query Editor as shown below
7. Before we click on “Generate”, we need to check the “Override default query processing” If we omit this step, all of our Input Parameters will default to an NVarChar Data Type with a field size of 1. We would have to start all over again with Step 1.
8. We have to select each Parameter and set its Type and Field Size. Setting the Sample Data value is optional.
9. Once completed we click on “Update Command”.
10. This brings us back to the Schema Generation page.
11. We can now click on “Generate”.
12. This time we have one Schema and an Orchestration generated.
We also have the same issue with Multi-part Message Types.
13. We need to set the Message type to the correct schema
14. Our generated schema is shown below
15. As you can see the correct data types are set for each parameter.
17. Our Orchestration is similar to our first demo, the only exception being a Send Port instead of a Send\Receive
1. We create a new stored procedure as shown below.
2. Next we must follow Steps 1 - 5 as in the previous demos.
3. On the Statement Type page , we will select Stored Procedure.
4 On the Statement Information page, we enter its name as shown below.
5. Click “Generate”
6. This generates two schemas and an orchestration as shown below.
Our Request Schema
Our Response Schema
We still have the same issue with the Multipart Message Types.
7. We set the correct schemas again.
8. Two Port Types are created. We need to delete these and create a new Request/Response Port.
9. Creating our new Request/Response Port
10. We are sending a Request and Receiving a response
11. Our new Request\Response Port as show below.
12. Next we create our Orchestration as shown below.
Because we are using a Stored Procedure that returns a value, we can add Exception Handling. In this case we are validating the result and throwing a System.Exception if the Stored Procedure returns an Error Code.
We will need to create two Send Ports, a Static Request-Response for our Select Table Operation and Stored Procedure Demos, and a Static Request Port for our Update Table Operation.
1. Open the BizTalk 2010 Administration Console and add a new Application called “ODBC Test” as shown below.
2. After deploying our demos, we need to configure a Static Solicit-Response Send Port as shown below.
3. Since we are using Windows Authentication for our ODBC Data Sources, we uncheck “Include UserID and Password” as shown below.
4. We select our Data Source Name and click “OK”.
5. Our ODBC Transport Properties are set as shown below.
6. We will also need to create a static one-way port a shown below.
7. We configure the Send Port by setting our Connection String.
8. We then click on the Connection String button.
9. We select our ODBC_Test Data Source as shown below
If our ODBC Data Source supports Transactions, you can select from the “Transaction type to be applied” list as shown below.
10. In the case of our scenario, we will leave it set to the default “None”
.
11. We will need to create a Receive Port and Location using the File Adapter for each Orchestration
12. We then Bind our Orchestrations to our new Ports and our ready for testing.
