Download Solution

This starts a series of articles about a BizTalk business process scenario. The entire solution can be downloaded from here:

https://1drv.ms/u/s!Athnq7Tlw-8Uhn1Ryz8nnnDnHkYo

Scenario Description

The Scenario is a modification of a real business case for a payment gateway.

The gateways acts as a medium between vendors and banks:

For example say a vendor V sells computer parts. This vendor wants to provide a service for their customers to pay through bank channels. Instead of having the vendor integrate with the bank, a central payment gateways orchestrates the integration. When having multiple vendors and multiple banks, the importance of having such payment gateway quickly becomes apparent.

There are 3 business processes in this scenario.

• In the first process (Bill Upload), vendors upload customer bills that are to be paid to the bank. This process is called Bill Upload.
• In the second process (Payment Notification), the bank notifies back the vendor about the paid bills. This process is called Payment Notification.
• And finally, a typical process in payment systems is something called Reconciliation (Bill Reconciliation). Here the bank sends to the vendor – as a kind of late night batch – a summary of all Txs done so that the vendor and the bank can reconcile any differences in records.

Demo Solution

The solution demo is divided into 3 logical parts:

• First, the BizTalk modules section is further divided in 4 sections; 1 section per process.
• For example, the Bill Reconciliation section contains 4 projects: 1 for the Ox, 1 for any custom pipelines, 1 for schemas,and 1 for outbound schemas. I will talk more about outbound schemas later, but basically these are the schemas that are expected by other parties and not the ones mandated by the central gateway…
• Similarly, the Bill Upload and the Payment Notification processes, has a similar structure. The Payment Notification has an additional console application which I will need to initiate the process using a WCF call.
• Just note that, this structure of dividing schema and pipeline artifacts into their own projects is a matter of a personal choice. In my opinion it provides better maintainability and manageability.
• The .NET assemblies section, contains 3 projects. The first two are custom pipeline components. And this one is a helper class I will call from one of the Oxs
• And finally, the solution contains one web application, which is deployed on my local IIS. This application is used by an HTTP adapter in the bill upload process. Just remember that if you end up with a different port that 80, you need to change the URL used in the HTTP adapter to run the sample.

Deploy Solution

Deploy BTS Projects

You can deploy the BizTalk projects from the properties page of each project. I have already included the signing key as part of each project.

From the deployment tab, change the name of the deployment server to the one that you’re using.

Note that the Orchestration project in all processes references the other pipeline and schema projects, so its enough to right click and deploy the Ox project and all the related projects will be deployed also.

After deployment; you need to do two things in the administration console.

Lets take for example the Bill Upload Process. If you right click the Ochestrations.BillUpload project, select properties and in the references tab you need to add these other biztalk projects that are needed; for example here, the Orchestrations.BillUpload project is using schema and pipeline artifacts from these two projects:

The same applies for the Orchestrations.BillReconciliation project and the Orchestrations.PaymentNotification.RealTime project.

The other thing you need to do is to import the bindings which contain all the ports and their bindings in an Ox. In the demo folder there is a folder called bindings; there are three binding files for each of the processes. For example to import the bindings for the billupload process right click the Orchestrations.BillUpload application in BTS administration and select import–>bindings–>select the billupload bindings file and then import.

Finally, I rely a lot on file adapters to quickly get a demo up and running, so again in the demo folder, inside drop folders, this folder contains the locations and files I use in the samples. Copy this folder and paste it on the C drive; if you prefer another location, you need to change the location of the file adapters used in the demo.

Deploy Components

The two pipeline components (PromoteRecCount and SetNSForMsgPN) must be installed in the pipeline components folder in the biztalk installation directory. They do not need to be deployed into the GAC.

As for the .NET component (XmlHelper) it must be deployed into the GAC. You can use GACutil tool for this; just note that you need to restart the host instance that will be hosting this pipeline for BizTalk to detect changes.

Prepare Database

The BillUpload process uses the WCF-SQL adapter which talks to a demo database. The script for this database can be found in the SQL Script folder inside the Demo folder. Run this script inside SQL management studio.

This script creates a database called demo. If you already have a database with the same name and you want to change the script to create a different database name, then you need also to update the SQL adapter configuration.

The SQL adapter is used in the send port SendSQLUpdate in the bill upload Ox project. From the WCF-SQL adapter configuration you have to do the needed changes to change the server name to your machine. And as I said, in case you changed the database name, then you have to reflect this here also.

Enjoy!

There are a lot of BizTalk concepts implemented in this solution. You can set it up and start learning. In the next few weeks I will post some articles examining the processes and some of these concepts