My blog entries are usually technical in nature. This entry is more of a marketing entry discussing how BizTalk 2004/2006 can be used to implement the following specific business scenario:
1) An insurance underwriter requires information (for example -> medical history) about an insurance applicant.
2) An internal application captures applicant information provided by the underwriter such as:
a) Applicants First Name/Last Name/ Middle Name.
b) Birth date.
c) Birth place.
3) The internal application then sends this information to a company called MIB. The underwriters query parameters (Last Name/ First Name etc) are then used to query a data repository at MIB. A result set of the query is then returned to the internal application from MIB. This result set contains information such as the medical history of the applicant.
4) The results from MIB are then displayed to the insurance underwriter to aid in the insurance application process.
Presently many North American insurance companies send/receive information to/from MIB over a dial up connection. Flat Files are sent and received back from MIB.
By December of 2006, all users of the current dial up process are to switch over to a new process provided by MIB as below:
All insurance underwriter requests are to be transmitted to MIB using a secure HTTP connection. The requests are to be sent in XML messages that conform to the Acord schemas. A synchronous HTTP response (XML) message will then be sent back over the same secure HTTP channel as the request. This response message contains the results of the query.
Below is a description of how the above new process can be implemented by BizTalk 2004 or BizTalk 2006.
1) Create a new BizTalk project that contains the Acord XSD schemas as below:
2) Typically a mainframe application may dump the underwriter requests to disk in a flat file or different format.
A configured BizTalk FTP or File Receive Port is then configured to pick up the files.
Note: The original request may be delivered by a different transport or stored to intermediate location as below:
HTTP
MSMQ
MQSeries
Sql Server
Oracle
DB2
Host Applications -> IBM, mainframe zSeries (CICS and IMS) and/or midrange iSeries (RPG)
Host Files -> Data adapter for host file systems on IBM mainframe zSeries VSAM datasets and midrange iSeries physical files
etc.
BizTalk contains many out of the box adapters that can be used to receive messages from all the above transports/locations and others not listed. If the needed adapter is not provided out of the box, then the BizTalk Adapter framework can be used to author your own custom adapter. Third party adapters can also be purchased.
3) Create internal XSD schemas to represent the internal messages.
For example, an XSD schema using flat file extensions would be created to represent flat files produced by the mainframe application.
4) Create BizTalk map(s) to transform the internal flat files to Acord XML messages.
5) Create the necessary BizTalk orchestrations for the business process.
6) Install a certificate on the BizTalk machine for the MIB secure HTTP requests using the Certificate Snap-in.
7) Create a BizTalk Solicit-Response Send port with a configured HTTP adapter for the MIB secure HTTP requests. The Send port is configured to use the installed certificate from step 6).
8) Create BizTalk map(s) to transform the Acord XML response messages to internal messages.
The above pretty well covers all the required BizTalk objects.
So why use BizTalk for the above MIB request/response loop or a similar business process:
1) This is what BizTalk server does. It integrates a companies internal applications together and also provides B2B capabilities.
2) A number of turnkey solutions can be purchased that do the same communication loop with MIB. These turnkey solutions are probably more expensive and proprietary than a BizTalk Solution. There is little coding involved to build the above BizTalk solution and there is complete control over the process as a developer(s) is building it and maintaining it. For changes or modifications to the BizTalk process, a configuration change is sometimes all it takes.
For BizTalk 2006 pricing go to HERE
For BizTalk 2004 pricing got to HERE
I have heard claims that it took more than 1000 man hours to complete the above process in BizTalk. This is completely untrue as it took me a fraction of 1000 hours to implement the above MIB communication loop using BizTalk.
3) The BizTalk server that hosts the above process can be used to host other developed Application Integration or
B2B business processes.
4) BizTalk server is increasing exponentially in popularity. More and more developers have BizTalk experience.
5) BizTalk provides many useful out of the box features such as:
a) Business Activity Monitoring
b) Rules Engine
c) Fault Tolerance/Load Balancing
d) Tracking
e) etc. etc.
Note: I do not mean to sugar coat the process. The BizTalk maps for the MIB requests and response messages are somewhat complex. The complexity of the maps can be attributed directly to the large size of the Acord XSD schemas. There are larger XSD schemas. In my opinion, the HL7 XSD schemas are more complex then the Acord XSD schemas.