Legacy Modernization with BizTalk Server 2006 and Host Integration Server 2006
Prepared by: Todd Sussman, Principal Consultant, Neudesic, LLC
To download a printer-friendly version of this document, click here.
The purpose of this guide is to serve as a scenario-based walkthrough around Microsoft® Host Integration Server (HIS) 2006 and Microsoft BizTalk® Server 2006. The scenario described gives context to the solution and provides details about the tasks associated with exposing functionality on IBM mainframe (z/OS) and AS/400 (iSeries) platforms. DB2 and VSAM host file access, initiating IBM transaction programs, and terminal-based applications will be exposed to the Windows® platform by using Host Integration Server and the BizTalk Adapters for Host Systems.
This document is not intended to be used as a product manual, although its style might resemble one. Detailed steps are included to illustrate the scope and nature of specific tasks as a generic guide of implementation.
Intended Audience
The intended audience for this paper is experienced BizTalk Server developers with limited knowledge of Host Integration Server. The user is not expected to have working knowledge of Host Systems.
Note Refer to the glossary for any terminology that is unfamiliar. For specific configuration and implementation details, please refer to the relevant product documentation and user guides.
Legacy modernization can range from replacing legacy systems with new servers that perform new tasks such as data warehousing and analysis, to integrating applications on the host with new or existing Windows applications.
Replacing z/OS and iSeries legacy applications may not always be an option. Applications can be mission-critical, and can have a proven record of reliability. Similarly, companies might not have the ability to replace existing hardware and infrastructure investments, or to incur the cost of rewriting mainframe applications.
Microsoft Host Integration Server 2006 enables enterprise organizations to integrate mission-critical host applications and data sources with solutions designed to consume Web services, regardless of their platform or programming language.
As part of the BizTalk Server 2006 Adapters for Host Systems package, customers get Microsoft Host Integration Server 2006. This allows extending BizTalk Server with direct-connect solutions where needed. The following scenario demonstrates the use of the HIS Session Integrator technology to address such a need.
The following is a banking scenario that illustrates how BizTalk Server 2006, Host Integration Server 2006, and the BizTalk Adapters for Host Systems can be used to solve the challenges that confront Woodgrove Bank. Woodgrove Bank, a fictitious banking scenario, is used throughout the paper to demonstrate how bank managers, account managers, and customers can benefit from modernizing legacy applications.
Woodgrove Bank is a small, single-branch bank that prides itself on supplying excellent customer service. To better serve the needs of its customers, Woodgrove Bank has decided to implement a new process for opening accounts. The new process will simplify and reduce the number of transactions that employees must execute to open an account. By eliminating the need to enter duplicate data, and by leveraging Web services for the interface, opening new accounts should take less time. By creating a new auditing system and using the BizTalk Business Activity Monitoring (BAM) component, a real-time view into the system is available.
To implement this process, Woodgrove Bank must integrate and orchestrate multiple legacy applications running on z/OS and the Windows platform, and add a new data source on an iSeries computer.
The Current Process
As the bank has grown, it has purchased new systems that do not always talk to each other. For example, Woodgrove Bank has a customer relations management (CRM) system that uses VSAM host files for storage. A separate system maintains customer and account records running in Customer Information Control System (CICS). While both systems reside on z/OS, they have different interfaces for updates. The end result is that account managers are inserting the same data multiple times.
The following diagram illustrates Woodgrove Bank’s current process for opening a new customer account.

Figure 1: Current Process for Opening a New Customer Account
The Business Problem
Woodgrove Bank recognizes the importance of upgrading its systems so that it can continue to grow and to service customers in a timely manner. Because cost is a major factor, the bank wants to move forward with new Windows applications that build on top of its existing investment instead of replacing that investment. By updating, the bank hopes to add agility to its business processes, reduce redundant tasks, and expose legacy applications in a service-oriented manner. The bank is also adopting a proactive stance toward monitoring its business processes. A requirement for all new systems is that they can publish all transactions to a new auditing system that will reside on an iSeries computer.
The User Problem
The account managers are required to log on to multiple interfaces, such as the CRM system, the account management system, and the cashiering system. Frequently, different systems require the same data. Because there is not a common data source or user interface, the user must supply the same data multiple times. Finally, the current applications all run from a terminal, and the users would like a more friendly application interface.
Below are examples of the various screens that the account managers are hoping to replace.

CRM System

Account Management System

Cashiering System
The Developer Problem
The developer must decide how to supply connectivity with the legacy applications. The developer is faced with questions such as:
-
What protocol is required to support the requirements?
-
How do I give access to legacy data?
-
What type of security is required?
-
How can I manage multiple logons for a single user?
The new design must incorporate the existing infrastructure, including hardware and legacy applications, yet allow cross-platform systems to communicate in a seamless fashion. The ability to route and transform messages, plus orchestrate individual transactions into a single service, while maintaining centralized management is crucial.
The Solution Design
By breaking down the requirements, it is possible to see how a Microsoft solution fits this problem space. The requirements include: z/OS and iSeries connectivity, session-level integration with several “Green Screens,” interaction with an IBM transaction program, and host file and DB2 access.
The proposed solution is based on Host Integration Server, BizTalk Server, and the BizTalk Adapters for Host systems. So, how do they solve the problems?
Host Integration Server supplies connectivity—in this case an SNA link, session-level integration, and the ability to interact with the IBM transaction programs. The BizTalk Adapters for Host Systems allow for direct access to host files and DB2, while the Adapter for Host Applications exposes the IBM transaction programs as services to be consumed. Last but not least is BizTalk Server. With BizTalk Server, it is possible to use orchestrations to create a single comprehensive service made up of disparate systems. The pub-sub model that BizTalk Server uses can be leveraged to create an event-driven model for the auditing system, while enabling these new services to be exposed as Web services.
Exposing the new services as Web services provides flexibility as to how the end-user interface will work. Perhaps it is a Windows application, or a Web page exposed to the account managers. Either way, the fact that all of the separate interaction points have been combined into a single point of entry will eliminate the need for duplicate data entry, and that was the main concern for the business user.
The following diagram illustrates the proposed workflow.

The Proposed Details
The CRM system is running on z/OS, and uses VSAM host files to store the data. By enabling direct access to these files, it is possible to query and update host files without going through the intended interface.
The account management application is a prepackaged and proprietary system. When purchased, it was never intended to talk to other systems, and the only access point is through a terminal-based, or “Green Screen” application.
The cashiering system is made up of several IBM transaction programs, and offers the ability to interact with them directly and not through the intended interface.
Finally, the new auditing requirement means that each step in the process will be required to publish a transaction message, and that a service will be needed that can subscribe to the messages. The back-end of the auditing system is DB2 on an iSeries, so direct access to that resource will once again allow you to avoid going through the intended interface.
Figure 2 shows four distinct operations that expose individual elements of the process as services. The BizTalk subscription model allows the orchestrations to pull the message they want from the MessageBox database, and repost it to the MessageBox when they are finished.
The operations need to provide the following functionality:
-
Verify the customer exists in the CRM system
The first operation is to discover whether the customer already exists in the CRM system. The customer’s CRM data is stored on VSAM files and a customer record needs to be read from a file based on a predefined parameter, for example, Social Security Number. If the customer exists, the query returns all the relevant data on that customer. If the customer does not exist, the customer needs to be added to the file. If a customer is added, a transaction event needs to be generated.
-
Update the Account Management system
After the customer has been added to the CRM system, this operation must add or update the same customer in the Account Management system, and open an account in the customer’s name. Since this application is designed to be triggered only by a “Green Screen,” it will be completed by using a 3270 Terminal Emulation to connect to CICS, and screen scraping to enter and retrieve data.
-
Use the Cashiering system
With an account open, use direct calls into IBM transaction programs to initiate operations on the z/OS such as initial deposit and balance verification.
-
Update the Auditing system
A global requirement is the ability to subscribe to transaction events thrown by the system. This operation is designed to subscribe to those events and update a DB2 instance.
The Proposed Solution Design Diagram

Figure 3: The Proposed Solution Design Diagram
The Solution Walkthrough
The following table summarizes the tasks and the integration tools needed for the implementation of the solution.
| Task | Integration Type | Integration Tool |
|---|---|---|
|
Configure network connections |
Network integration |
SNA Manager |
|
Verify that the customer exists in the CRM system |
Data file integration |
BizTalk Adapter for Host Files |
|
Update the Account Management system |
Screen-based integration (screen scraping) |
Session Integrator |
|
Use the Cashiering system |
Transaction integration |
BizTalk Adapter for Host Applications |
|
Update the Auditing system |
Database integration |
BizTalk Adapter for DB2 |
The following sections discuss each of these tasks in detail.
When using Host Integration Server (HIS), some tasks are reusable across several processes. This includes: Creating an SNA Link Service, 3270, and APPC connection and Logical Units.
Creating an IP-DLC SNA Link
This scenario uses IP-DLC instead of straight TCP for several reasons. One of the requirements is to interact with VSAM host files on a mainframe. The BizTalk Adapter for Host Files relies on the Distributed File Manager (DFM) which supports only SNA connections. IP-DLC allows for SNA connections, with the added benefit of using the IP protocol, but this is not the only reason to consider using IP-DLC. For example, if a requirement existed for distributed transactions with CICS, it would have to leverage the CICS Transaction Manager, and this also requires an SNA link.
The first step in using Host Integration Server is to create a link service; in this case, an IP-DLC link service.
To create a link service-
Open SNA Manager and right-click the server on which to create the service.
-
Click Start, point to All Programs, and then click Microsoft BizTalk Adapters for Host Systems.
-
Select New , point to Link Service, point to Select IP-DLC as the type.
The Online-Demo IP-DLC Link Services Properties dialog box appears.

-
Set the following values in the Properties dialog box.
Value Description Service Name
The name of the Windows service is automatically assigned.
Service Title
The “user-friendly” name assigned to this link service.
Primary NNS
The IP address; Wins or DNS name can be used.
Adapter Address
The network adapter used by Host Integration Server or a static IP.
Network Name
The APPN node identification specifies the name and identity under which the Branch Network Node that is implemented by the IP-DLC link service will be visible in the APPN network. The HIS IP-DLC link service appears as an EN node for the NNS.
Control Point Name
The Control Point Name must be unique for this computer on the APPN network.
Node ID
In the first box, enter any valid 3-digit hexadecimal number, except the reserved numbers 000 and FFF. In the second box, enter any valid hexadecimal number, except the reserved number 00000. There is no default value.
-
The APPN node can be created dynamically on the host. By using 05D FFFFF, the PU is dynamically created. You can also select the Use Dynamic PU Definitions box.
-
Click OK.
-
A dialog box appears so the credentials that the service will run under can be entered. Supply a service account user.
-
Click OK.
-
The original Insert Link Service dialog box appears. Click Finish, unless additional link service information is required.
-
Right-click SNA Service and select Properties to verify the following SNA Service Properties.
Property Description Network Name
The name of the network for this SNA service. This is the default network.
Control Point Name
The Control Point Name must be unique; for example, the first eight characters of your computer name.
-
Save the configuration before continuing.
Configuring a 3270 Connection
In the hierarchical SNA network model associated with a mainframe computer, centralized applications are accessed from remote terminals across a network.
The 3270 information display protocol for the IBM mainframe facilitates conversations between the mainframe and devices such as terminals, printers, and controllers. Host Integration Server 2006 provides access to these mainframe resources through the definition and assignment of 3270 logical units (LUs).
To configure a 3270 connection, use the 3270 Emulation Configuration Wizard that is supplied with Host Integration Server 2006.
To configure a 3270 connection-
Using SNA Manager, right-click the SNA Service, point to All Tasks, then click 3270 Wizard.
-
Select the SNA Service to configure.
-
Assign a user-friendly name to the connection.
-
Select the Link Service.
-
Enter the Local Node ID information.
IDBLK and IDNUM identify corresponding values that are defined in a PU definition on the host side.
Note This information is not arbitrary. You must get the exact information from your system administrator. 
-
Click Next.
-
Enter the DLUS properties.
Note These properties will also be supplied by your system administrator. Property Description DLUS
The SSCPNAME for the Control Point Name in the VTAM configuration.
Network name
The NETID name in the VTAM configuration.
Number of LUs
The number of LUs assigned to this connection.
-
Create the LUs.
Value Description Base LU Name
A user-friendly name that is the start of each LU’s name.
Starting LU Number
The number at which to start the LUs.
Number of LUs
The number of LUs assigned to this connection.
-
Assign users to the LUs.
-
Click Finish. A dialog box appears. Click OK, and save the configuration.
Configuring the Peer System Connection
A peer-oriented SNA network that uses the Advanced Program-to-Program Communications (APPC) protocol relies on each device in the network to communicate directly with the other devices. Each computer depends primarily on its own intelligence and does not require constant access to a centrally located host computer.
APPC supports display and other application services across an SNA network. Although peer-oriented SNA networks are usually associated with an AS/400 host system, mainframe systems can also support peer-to-peer networking.
To configure the peer system connection-
Right-click SNA Service, point to New, and then select IP-DLC.
A dialog box appears. Enter the connection Name. Select the Link Service and Remote end.
-
Right-click the Local APPC LUs folder in SNA Manager and choose New, then select Local LU.
Enter the LU alias. This will match the independent LU assigned to you by your system administrator.
Note The LU alias can be any value, but the LU name must match the value assigned to you by the Host Access request. -
Right-click the Remote APPC LUs folder in SNA Manager and choose New, then select Remote LU.
Select the Connection and enter the LU alias. The LU name and Uninterpreted name match the name of APPLID or the ACBNAME statement in VTAM. You might have to create multiple remote LUs if you are connecting to different systems. For example, one remote LU might point to CICS while other remote LUs point to host files or a DB2 database.
-
Right-click each remote LU that was created and assign a user.
-
Save the configuration, and refresh the SNA service.
-
Start the SNA service.
Both connection types should be active.
One of the major requirements in this scenario is to retrieve or update data in the CRM system hosted on the mainframe. The CRM system is using VSAM host files as its data store, and by using the BizTalk Adapter for Host Files, you can access them directly without the need to use the CRM application.
This section of the document will cover tasks that are required when using the BizTalk Adapter for Host Files.
Accessing the Host Files
To access data records stored in IBM mainframe z/OS (VSAM) datasets and midrange iSeries physical files, enterprise developers can use the Microsoft .NET Framework Data Provider for Host Files that is based on an updated Microsoft network client for host files (nested records, SQL commands). The host file provider includes a Microsoft Visual Studio® 2005 design tool. The design tool has COBOL and RPG source code import wizards that enable developers to map host program-described records to ADO.NET data tables. The .NET Framework Data Provider offers basic SQL commands (SELECT, INSERT, UPDATE, DELETE) and built-in data conversion from host machine types, including nested records (COBOL OCCURS, COBOL REDEFINE, and RPG OVERLAY) and EBCDIC strings, to .NET Framework CLS data types and Unicode. In addition, the BizTalk Adapter for Host Files is supplied to connect to the host files, and eliminate the need for custom code.
Creating a Host File Library
One of the key differences between a host file and a database table is that the host file doesn’t have the metadata that describes the structure of the data.
To access the host dataset, you must define the metadata associated with this dataset by using the Host File Designer. The need for the metadata assembly arises from the fact that DFM doesn’t have any control of the type and number of fields in a dataset. The only definition enforced by DFM is the record layout and size; therefore an external means of storing this metadata needs to be created. The Host File Designer is a Visual Studio 2005 designer for defining the host dataset format.
To create a host file library-
Using Visual Studio, create a Blank Solution, and add a new project.
The project will be a Host Integration Projects/Host File Project.
-
After the project has been added to your solution, you must add a Host File Library. Right-click the new project and add a new Host File Library. The Host File Library Wizard starts.
-
Define the Host Environment type.
The two options are OS/390 (z/OS) or AS/400 (iSeries). For this scenario, you are querying a mainframe, so choose OS390.
-
Complete the wizard to create an empty assembly.
After the assembly is created, you must define the data structures.
-
Double-click the new assembly in Solution Explorer. Right-click the top node (the name of the new interface) and select Import, then select Host Definition.
The source file is imported, and Host Integration Server creates the data structures for you.
-
You must point to the COBOL Copybook.
Contact your mainframe administrator and get a copy of the source file for your local machine.
-
Click Next. A list of the structure members associated with the host file is displayed. Select the structure member you want.
-
Complete the wizard.
The new data structure is displayed in Visual Studio .NET 2005.

-
To add a table to the assembly, right-click Tables and select Add Table. In the Properties dialog box, assign an alias, Host File Name, and use the drop-down box to assign a schema.
-
You must define properties for the interface. To deploy this assembly to the global assembly cache (GAC), you must assign a strong named key file (SNK). Right-click the top-level node. In the Properties dialog box, expand the Assembly Information section. Enter the path and key name in the KeyFile section.
-
Save the file.
Saving the file is the equivalent of building a regular assembly.
-
Add the new assembly to the GAC and register the assembly. You must execute the following commands to register the host file.
GACUTIL –I %DLL Location%\DLLName.dll REGASM %DLL Location%\DLLName.dll
Creating a Host File Connection String (z/OS)
Use the following procedure to create a host file connection string.
To create a host file connection string-
Click Start, point to Programs, point to Microsoft BizTalk Adapters for Host Systems, and then click Data Access Tool.
-
In the Data Access Tool console, on the File menu, point to New, and then click Data Source.
-
On the Data Source page, in the Data source platform box, select the Source Platform (Mainframe or AS\400) file system.
-
Under Network type, click the connection type to use, and then click Next.
Note If you are connecting to a mainframe, only the SNA connection is available. 
-
On the APPC Network Connection page, provide the information in the following table.
Property Value Local LU alias
The Local LU defined in SNA Manager.
Remote LU alias
The Remote LU defined in SNA Manager for the host system you are connecting to.
Mode name
The Mode Name for this system, supplied by a system administrator.
-
Click Next.
-
On the Mainframe File System page, provide the information in the following table.
Property Value Default library
The default location for the host files.
Host File Mappings
Browse to the assembly created in the preceding step.
-
Click Next.
-
On the Locale page, accept the defaults and click Next.
-
On the Security page, select the security model required and enter the relevant information. Click Next.
Note This can be either interactive or Single Sign-On. -
Advanced Options are not supported, so click Next.
-
The Validation page is displayed. You can test the connection to the host file system and, optionally, execute a sample query. Click Next.
-
On the Saving Information page, type a friendly name in the Data source name box.
-
Under OLE DB or Managed, select Universal Data Link, and click Next. Click Finish.
Generating a Schema BizTalk Adapter for Host Files
Use the following procedure to create a BizTalk Adapter for host files.
To generate a schema for BizTalk Adapter for host files-
Right-click a BizTalk project. Select Add, point to Generated Item, and then select Adapter Metadata. Select the Host File Adapter and click Next.
The Host File Adapter Schema Generation Wizard appears. Click Next. Add the connection string that was created.
-
Select the source system. The source system is an AS/400 iSeries or a mainframe. This section focuses on mainframes, which are limited to just an SNA connection.
-
Select the local LU, the remote system to connect to, and the mode.
The system administrator should be able to provide this information. You must define the Default Library. (This is the section of the VSAM where the files are located.) Browse to the assembly that you created earlier.
-
Assign the security method and credentials.
-
Accept the defaults for Advanced Options, which are not supported by the Host File Adapter. Click Connect to validate the connectivity.
-
Assign the Target Namespace for the documents. Set the Port Type and the Root Node names.
Note This is similar to using the SQL adapter. There are many similarities between the Host Integration Data adapters and the SQL adapter. 
-
Select Updategram or Select statement.

-
Click Finish.
BizTalk Server generates a schema and an orchestration that defines a multipart message.
Note This solution creates an Updategram to insert new customers into the host file, if they do not already exist.
Creating a BizTalk Orchestration to Query the Host Files
You use an orchestration to call the BizTalk adapters and metadata. Using the design goals in Figure 3 the orchestration must execute a query, possibly insert a new customer, and publish messages to the MessageBox database. The following diagram illustrates this orchestration.

Figure 4: BizTalk Orchestration to Query VSAM
The orchestration in Figure 4 starts by subscribing to a NewCustomer message. The message is transformed into a format that is expected by the Host File Adapter in the send pipeline. The message is sent to query for an existing customer and waits for a response. If the customer exists, the orchestration moves to the end. If the customer does not exist, a new customer is added.
To add a customer, the send port transforms the message into an Updategram as defined by the adapter wizard, and a new message is sent to the audit system that a transaction has occurred. Finally, a new message is created to add an account to the customer, and then published to the MessageBox.
Configuring a Host File Adapter Send Port
Use the following procedure to configure a host file adapter send port.
To configure a host file adapter send port-
Open the BizTalk Server Administration MMC. Browse to the application where the orchestrations are deployed, and create a new static solicit-response port.
-
Select MsHostFile as the type, and click Configure.
-
Supply a pre-existing connection string, or create a new string. Use the same procedure that was used to generate the adapters. Supply the same Target Namespace and Response Root Element.

With the customer in the CRM system, the customer must be added to the Account Management system, and the account must be opened.
Session Integrator is one piece of Host Integration Server that does not have a BizTalk adapter. You must create a series of methods that you can call from an Expression shape to interact with Session Integrator. Some of the sample code is shown below with screen shots of the terminal application.
To add a customer-
Open a BizTalk project, and create a reference to Microsoft.HostIntegration.SNA.Session.dll.
It is located in the <Install Path>\Microsoft BizTalk Adapters for Host Systems\system folder.
-
Add an orchestration. Use an atomic scope for Session Integrator.
-
Microsoft.HostIntegration.SNA.Session.dll is non-serializable, so the variable must be created in an atomic scope.
-
Create a variable of a SessionDisplay type.
-
In an Expression shape, add code similar to the following steps.
-
Initialize the variable, and connect to the host system.
m_Handler = new SessionDisplay(); m_Handler.Connect(strConnection);
Sample Connection String:
"TRANSPORT=SNA;LOGICALUNITNAME=" + this.InputLUNameBox.Text.Trim().ToUpperInvariant());
-
Set a value indicating the type of host code set identifier (CCSID) for the current instance.
m_Handler.Connection.HostCodePage = 37;
Wait for the specified fields, partial fields, or search strings to appear on the screen.
m_Handler.WaitForContent("TERM NAME", 20000); -
Send a key that identifies the CICS region to log on to.
m_Handler.SendKey("LOGON APPLID(" + CICSName + ")@E");
Wait for the session to enter the specified state.
m_Handler.WaitForSession(SessionDisplayWaitType.PLUSLU, 20000); m_Handler.WaitForContent(@"DEMONSTRATION", 20000);

m_Handler.SendKey("WBAA@E"); m_Handler.WaitForContent("F9=Add Acct", 5000); _Handler.SendKey(SessionDisplayKeys.EraseInput.ToString() + _street + ((_street.Length != MaximumStreetLength) ? SessionDisplayKeys.Tab.ToString(): "")); Handler.SendKey(SessionDisplayKeys.EraseInput.ToString() + _city + ((_city.Length != MaximumCityLength) ? SessionDisplayKeys.Tab.ToString(): "")); _Handler.SendKey(SessionDisplayKeys.EraseInput.ToString() + _state); _Handler.SendKey(SessionDisplayKeys.EraseInput.ToString() + _zip); _Handler.SendKey(SessionDisplayKeys.EraseInput.ToString() + _phone + SessionDisplayKeys.Enter.ToString());
-
Get the current field where the cursor is located.
m_Handler.CurrentField.Data = _name; m_Handler.MoveNextField(new ScreenFieldAttributeData(ScreenFieldAttribute.Normal)).Data = (accountType == AccountType.Checking ? "C" : "S"); m_Handler.SendKey(SessionDisplayKeys.Enter);

-
Close the connection.
m_Handler.Connection.Dispose();
Now that the account has been created, the next step is to run several transactions against it, such as initial deposit and balance verification, via the Cashiering system. These are transactional programs that reside on the mainframe. Because the business logic and presentation layer are separated, Transaction Integrator (TI) will not require any modifications to the programs.
Configuring a Remote Environment
Use the following procedure to configure a remote environment.
To configure a remote environment-
Start TI Manager. Expand the Transaction Integrator folder.
-
Right-click the Remote Environments folder, point to New, and then click Remote Environment.
-
Select the Remote Environment (RE) that matches your programming model, and then click Next. For this scenario, we used CICS ELM Link.
Note The Remote Environment must match the protocol, the target environment, and the programming model used by the assembly. -
Enter the requested information in the dialog boxes that follow, and then click Finish.
Creating a .NET Client Library with TI Interface Definition
Use the following procedure to create a .NET client library.
To create a .NET client library-
In a Visual Studio solution, choose File, point to New, and select Project to add a new project.
-
Select a Host Integration Server Project and Transaction Integrator Project type.
-
Right-click the new project, and add a new .NET Client Library.
After you name the library, a wizard opens to help create the assembly. Because this scenario requires creating a series of banking interfaces, the name of the new assembly is Banking. The first interface is directed at an application that interacts with an account, so the first interface is named Account. The dialog box should look like the following.
Note For the Type Restrictions box, you must state that you are using the BizTalk Adapter for Host Applications. This eliminates any options not supported by the adapter. 
-
Click Next. The next dialog box identifies the host environment.

-
Once again, the programming model must match the corresponding RE type in the assembly that was created. In this case, it is ELM Link. Click Next to finish creating the empty assembly.
Note ELM Link is the Enhanced Listener Message used by TCP. -
The host data structures must be defined. Open the new assembly in Visual Studio .NET 2005, and right-click the root node. Select Import, and then select Host Definition.
A new wizard is displayed. The first dialog box enables a developer to browse to a sample COBOL file, so that Host Integration Server can automate the process of defining the data structures. This example uses Discriminated Unions, so there are special modifications that must be made to the assembly after it is completed.
Note COBOL and most mainframe languages often "redefine," or reuse, an area in a record to save space. The same data buffer might have multiple record types associated with it. A client program that reads the buffer, such as HIS Transaction Integrator, must determine which record type to use when interpreting the data for each record instance. The record selection is based on a Discriminant field value. This featured is called “Discriminated Unions” in HIS, and the feature is demonstrated in the following pages. 
-
Click Next. Select the type of structures to create.

-
Click Next. Select the COBOL group.

-
Click Next. Define the direction of the parameters.

-
Click Next. In this solution, the defaults for the next dialog box are acceptable.
-
Click Next, then select Modify.
Transaction Integrator has been extended to support dynamic redefinitions of COBOL (redefine) and RPG (overlay) as Discriminated Unions for both Windows-initiated processing and host-initiated processing. This enables enterprise developers to reuse complex host business rules to access data areas defined with varying data descriptions.
-
To set the union, expand the Banking interface, expand the GetAInfo method, and then expand the ACCT_ARRAY parameter. Right-click Union1 and select Properties.

-
Set the Discriminant, and set the “Condition” for the union in the DVT field. In the properties of the Interface, select your Remote Environment and save.
Note |
|---|
| By importing the host definition file into the .NET client library, HIS Designer also creates an XML schema data (XSD) file. This XSD file contains the interface definition you will use later in your BizTalk application. You may view the XSD file by clicking the XSD Definition tab in HIS Designer. The XSD file should be saved in the standard location for the project. Note that you will need this location when you add the XSD file to your BizTalk project. |
Creating a Host Application Send Port
Use the following procedure to create a host application sent port.
To create a host application send port-
Open the BizTalk Administration console, and expand the application where the send port will be created. Under Send Ports, create a new Solicit Response Send Port. Select the Host Application Adapter to configure the Properties.
-
The Host Type is made up of three properties:
-
The first part is always TI (Transaction Integrator).
-
The second is the Remote Environment (RE) that was defined earlier.
-
The last part is an optional RE Override.
-
The first part is always TI (Transaction Integrator).
-
By enabling Persistent Connections, the Transaction Integrator can use persistent connections when processing a batch of messages.
Note Persistent Connections will only take effect if the IBM transaction program supports this. -
Select Transactions: Enables 2-Phase Commits.

-
Select the pipelines to use, and any advanced options that might be required.
DB2 access is required because of the new Auditing system. To automate this feature, an orchestration will be created that subscribes to a NewTransaction message. By using the BizTalk Adapter for DB2, it is possible to execute common SQL commands against DB2.
Accessing a DB2 Database
The Microsoft .NET Framework Data Provider for DB2 can be used to directly access information in IBM DB2 database servers. The Data Provider for DB2 is based on an improved Microsoft network client for DB2 (pooling, schemas, transaction, static SQL). The DB2 Managed Provider extends the standard Visual Studio 2005 design tools, Solution Explorer and Dataset Designer, to enable enterprise developers to generate code based on intuitive drag-and-drop and wizards.
Creating a DB2 Connection String
Use the following procedure to create a DB2 connection string.
To create a DB2 connection string-
Click Start, point to Programs, point to Microsoft BizTalk Adapters for Host Systems, and then click Data Access Tool.
-
In the Data Access Tool console, click the File menu, point to New, and then click Data Source.
-
On the Data Source page, select DB2/AS400 in the Data source platform box.
-
Under Network type, click protocol to be used, and then click Next.
Note TCP/IP has less overhead, and is the preferred method. -
On the APPC Network Connection page, provide the information in the following table.
Property Value Address or Alias
The Primary NNS.
Port
The port to be used.
-
Click Next. The DB2 Database page is displayed. Enter the information that is described in the following table.
Property Value Initial Catalog
Database name
Package Collection
Where the data provider binds to DB2 packages
Default Schema
Table name
Default Qualifier
Table name

-
Click Next. Leave the default values for the Locale settings, and then click Next.
-
On the Security page, leave the default settings. Click Next.
-
On the Advanced Options page, select the options that apply. Click Next.
The Validation page is displayed. You can test the connection to the DB2 system, and optionally, create packages or retrieve a list of tables.
-
Click Next.
-
On the Saving Information page, type a friendly name in the Data Source Name box.
-
Under OLE DB or Managed, select Universal Data Link and Initialization string file. Click Next, and then click Finish.
Generating Schema for BizTalk Adapter for DB2
Use the following procedure to create a DB2 adapter in BizTalk Server.
To generate schema for BizTalk Adapter for DB2-
Right-click the BizTalk project and select Add, point to Generated Item, and then select Adapter Metadata. Select the DB2 Adapter and click Next.
The DB2 Adapter Schema Generation Wizard is displayed. Click Next. Select Create New Connection String. Add the connection string that you created earlier.
-
Select the source system.
The source system will be an iSeries or a z/OS. You can choose whether to use an SNA connection or a TCP/IP connection. The TCP/IP connection has less overhead, and is the preferred method.
-
Add the address of the computer hosting the DB2 instance and the port on which to communicate. Set the initial catalog, package collection, and default schema and qualifier. Assign a security method and credentials.
-
Set the Advanced features, such as connection pooling. Click Connect to validate your connectivity. Click Packages, so you can execute SQL-style statements on your DB2 installation.
-
Assign the target namespace for the documents.
-
Set the port type and root node name.

This is similar to using the SQL adapter.
-
You can choose whether to use an Updategram or a Select statement.
This scenario uses an Updategram.

-
Click Finish.
BizTalk Server generates a schema and an orchestration that defines a multipart message.
Creating a BizTalk Orchestration to Insert Transactions in a DB2 Database
With the BizTalk adapter and metadata created, you want to use an orchestration to control the call to the DB2 database. Following the design goals in Figure 3 use the orchestration to insert a new record into a DB2 table. Subscribe to a BizTalk operation “PublishNewTransaction,” and map the input data to the format that the DB2 adapter works with. Call the DB2 adapter, wait for a response, and end the transaction.

Figure 5: BizTalk Orchestration to Call DB2
Configuring a DB2 Send Port
Use the following procedure to configure a DB2 send port.
To configure a DB2 send port-
Open the BizTalk Server Administration MMC. Browse to the application where the orchestrations are deployed, and create a new static solicit-response port.
-
Select MSDb2 as the type, and click Configure.
-
Supply a pre-existing connection string, or create a new string. Use the same procedure that was used to generate the adapters. Supply the same Target Namespace and Response Root Element.
When dealing with both Windows-based applications and Host System-based applications, the applications generally are not designed to use a common authentication mechanism. Enterprise Single Sign-On (SSO) servers can provide that service, assuming the middleware was designed to integrate with SSO. BizTalk Server and Host Integration Server were both designed to support SSO.
In this scenario, the initial call into the system is through a Web service. SSO tickets are the preferred method of maintaining credentials as the process crosses platform boundaries.
SSO Tickets
SSO services provide an SSO ticketing mechanism to enable enterprise application integration (EAI) products to deal with the problem of maintaining a user token across multiple computers and processes. This lets the user achieve a single sign-on in a secure manner by using Enterprise Single Sign-On. This is based on issuing a ticket on one computer (or by a certain process), and then redeeming the ticket on a different computer (or by a different process). Issuing a ticket means that a component calls into the SSO service to obtain an SSO ticket that represents the Windows user. Redeeming the ticket means that a component provides the ticket to the SSO service to obtain the host credentials corresponding to the Windows user that initiated the original request.
An SSO ticket is issued only to an authenticated user for making a request on an individual basis. In other words, User A can obtain only a ticket for User A. Even an SSO administrator cannot request a ticket for another user. The user making the request to obtain a ticket must be a valid authenticated domain user. If the user is Anonymous or not a valid domain account, then access will be denied when a request to obtain the ticket is made.
The ticket generated by SSO services primarily contains the user logon identity (domain\userid) and a time stamp indicating when the ticket was issued. This ticket is encrypted by SSO services. There is also a ticket time-out value configured at the SSO system level that determines when the ticket will expire. The ticket can be redeemed by a service account that is a member of the Application Administrators account for an Affiliate Application.
The Woodgrove Bank scenario started with several disparate legacy applications that resided on a Host System. These systems ranged from the CRM and a series of transaction programs on a z/OS to a DB2 instance on an AS\400. The bank wanted these systems to communicate with Windows-based applications and to be orchestrated into a cohesive process.
The approach taken was to leverage Host Integration Server to enable connectivity with the various systems. On top of that, BizTalk Server and the BizTalk Adapters for Host Systems allowed a means of controlling the flow of information from system to system, and exposing the host-based services as Web services.
The CRM system had VSAM host files as its means of storage, while the new auditing system used a DB2 instance. The BizTalk Adapter for Host Files and the BizTalk Adapter for DB2 were able to expose these resources in a manner similar to the SQL adapter. This makes it easy for an experienced BizTalk developer to quickly integrate those systems into a BizTalk process.
By using the BizTalk Adapter for Host Applications, transactional programs can be called from an orchestration and appear as just another service that BizTalk Server is designed to consume.
The hardest aspect of this scenario was interacting with an application designed to run inside a terminal. Without any easily accessed entry point into the application, BizTalk Server had to rely on the screen-scraping technology in Session Integrator. Since Session Integrator does not have a BizTalk adapter, custom code was written into an Expression shape that enabled integration at the session level.
The developer is able to use this service to create a friendlier user interface for the account managers. The account managers will realize their goal of a single point of interaction for this service.
Lastly, by using BizTalk Server and the Host System adapters, it was possible to incorporate the existing investment in hardware and various systems into a service-oriented strategy.
Sample Insert with an Updategram
<ns0:AuditUpdateReq xmlns:ns0="Http://Samples.Microsoft.Com">
<sync>
<after>
<CUSTOMERS CUSTOMERID=" " SSN=" " CONTACTNAME=" " CONTACTTITLE=" " ADDRESS=" " CITY=" " REGION=" " POSTALCODE=" " COUNTRY=" " PHONE="PHONE_9" FAX=" " />
</after>
</sync>
</ns0:AuditUpdateReq>
Sample Select Statement
<ns0:CustReq xmlns:ns0="http://Samples.Microsoft.Com">
<sync>
<Select>SELECT * FROM CUSTOMER WHERE KEY(SSN) EQUALS ‘SSN’ </Select>
</sync>
</ns0:CustReq>
Sample TI (Windows Initiated) Call
<ns0:Banking__Account__GetAInfo__Request TIAssemblyVersion="1.0" xmlns:ns0="http://microsoft.com/HostApplications/TI/WIP">
<ns0:GetAInfoInDocument ContainsUnion="true">
<ns0:SSN>SSN_0</ns0:SSN>
<ns0:ACCT_ARRAY>
<ns0:ACCT_ARRAY>
<ns0:ACCT_NUM>ACCT_NUM_0</ns0:ACCT_NUM>
<ns0:ACCT_TYPE>ACCT_TYPE_0</ns0:ACCT_TYPE>
<ns0:UNION1 IsUnion="true">
<ns0:Simplestring SimpleType="string">Simplestring_0</ns0:Simplestring>
</ns0:UNION1>
</ns0:ACCT_ARRAY>
<ns0:ACCT_ARRAY>
<ns0:ACCT_NUM>ACCT_NUM_0</ns0:ACCT_NUM>
<ns0:ACCT_TYPE>ACCT_TYPE_0</ns0:ACCT_TYPE>
<ns0:UNION1 IsUnion="true">
<ns0:Simplestring SimpleType="string">Simplestring_0</ns0:Simplestring>
</ns0:UNION1>
</ns0:ACCT_ARRAY>
</ns0:ACCT_ARRAY>
</ns0:GetAInfoInDocument>
</ns0:Banking__Account__GetAInfo__Request>
Sample TI (Windows Initiated) Response
<ns0:Banking__Account__GetAInfo__Response TIAssemblyVersion="1.0" xmlns:ns0="http://microsoft.com/HostApplications/TI/WIP">
<ns0:GetAInfoOutDocument>
<ns0:ACCT_ARRAY>
<ns0:ACCT_ARRAY>
<ns0:ACCT_NUM>ACCT_NUM_0</ns0:ACCT_NUM>
<ns0:ACCT_TYPE>ACCT_TYPE_0</ns0:ACCT_TYPE>
<ns0:UNION1 IsUnion="true">
<ns0:Simplestring SimpleType="string">Simplestring_0</ns0:Simplestring>
</ns0:UNION1>
</ns0:ACCT_ARRAY>
<ns0:ACCT_ARRAY>
<ns0:ACCT_NUM>ACCT_NUM_0</ns0:ACCT_NUM>
<ns0:ACCT_TYPE>ACCT_TYPE_0</ns0:ACCT_TYPE>
<ns0:UNION1 IsUnion="true">
<ns0:Simplestring SimpleType="string">Simplestring_0</ns0:Simplestring>
</ns0:UNION1>
</ns0:ACCT_ARRAY>
</ns0:ACCT_ARRAY>
</ns0:GetAInfoOutDocument>
</ns0:Banking__Account__GetAInfo__Response>
3270 Terminal
The IBM 3270 terminal or Display Device is used to communicate with IBM mainframes. Unlike common serial ASCII terminals, the 3270 minimizes the number of I/O interrupts required by accepting large blocks of data called data streams, and uses a high-speed proprietary communications interface. The IBM 3270 protocol is generally used via emulation to access some mainframe-based applications. In some situations, such as call centers, the terminal-based 3270 interface (“Green Screen”) is still the most productive and efficient.
APPC
Advanced Program to Program Communication (APPC) is an IBM protocol used to communicate over a network. APPC is at the application layer in the open systems interconnection (OSI) model. APIs were developed for programming languages, such as COBOL or REXX.
APPC was developed as a component of the IBM System Network Architecture (SNA). APPC is limited to the IBM operating systems iSeries (AS/400), OS/2, and AIX. Major IBM software products, such as CICS, DB2, CIM, and z/OS (MVS) include support for APPC.
APPC communication partners can be both servers and clients. The type of parallel session and the number of parallel sessions between the partners is negotiated over Change Number Of Session (CNOS) with a unique log mode, for example, snasvcmg. Data is communicated in data sessions. Log modes can be determined in detail from the VTAM administrator, for example, length of the data blocks and coding. APPC is the protocol used with LU6.2 architecture.
Microsoft includes SNA support in Microsoft Windows Server® editions.
CICS
Customer Information Control System (CICS) is a transaction server that runs on IBM mainframe systems under z/OS or z/VSE. CICS is available for other operating systems, such as i5/OS and OS/2, and as the IBM TXSeries software on AIX, Windows, and Linux.
CICS is a transaction-processing system designed for both online and batch activity. CICS provides management for business applications. On large IBM zSeries and System z9 servers, CICS supports thousands of transactions per second. CICS applications can be written in numerous programming languages, including COBOL, PL/I, C, C++, IBM Basic Assembly Language, REXX, and JCL (Java Control Language).
DB2
DB2 is the family of IBM data server software products in the IBM Information Management software line. Although there are versions of DB2 that run on other devices, DB2 generally refers to the IBM relational database management system (RDBMS) DB2 Enterprise Server Edition or the DB2 Data Warehouse Edition (DB2 DWE), which runs on Unix servers, Windows servers, Linux servers; or DB2 for z/OS.
IP-DLC
Internet Protocol - Data Link Control (IP-DLC) is another evolution of SNA, providing a means for the efficient transport of SNA data across an IP network. IP-DLC, also known as Enterprise Extender (EE) is an industry-standard solution defined by the Internet Engineering Task Force (IETF) (RFC 2353). With IP-DLC, the RTP endpoint views its interface with the Universal Datagram Protocol (UDP) layer of the stack as just another data link control, and treats the connection across the IP network the same as it would any SNA connection.
Logical Unit (LU)
A logical unit (LU) is an access point through which a user or application program accesses the SNA network to communicate with another user or application program. SNA defines several kinds of devices, identifying each group with a logical unit grouping, for example, LU1 devices are printers, LU2 devices are terminals that display 3270 device data stream, LU3 devices are printers using 3270 protocols, and LU6 provides for protocols between two applications.
LU6.2
LU 6.2 is a device-independent SNA protocol used for peer-to-peer communications between two systems, for example, between a computer and a device. The LU6.2 definition provides a common API for communicating with compliant devices and controlling compliant devices. APPC is the protocol used with LU6.2 architecture. APPC is used to refer to the LU6.2 architecture or to specific LU6.2 features. CICS Intersystem Communications (CICS ISC) uses the LU6.2 protocol.
MVS
Multiple Virtual Storage (MVS) is the primary operating system that runs on IBM mainframe computers. MVS was first released in 1974, renamed MVS/XA (eXtended Architecture), MVS/ESA (Enterprise Systems Architecture), OS/390 when UNIX System Services (USS) were added, and z/OS when 64-bit support was added on the zSeries models. Its core remains fundamentally the same operating system. By design, programs written for MVS can run on z/OS without modification.
The main interfaces to MVS are Job Control Language (JCL), a batch processing interface, and Time Sharing Option (TSO), an interactive time-sharing interface, which is a standard component.
MVS is typically used in business and banking, and applications are generally written in COBOL. COBOL programs are used with transaction processing systems such as CICS. For a program running in CICS, EXEC CICS statements are inserted in the COBOL source code. A preprocessor (translator) replaces those EXEC CICS statements with the appropriate COBOL code to call CICS before the program is compiled. Applications can also be written in other languages such as C, C++, Java, assembly language, FORTRAN, BASIC, RPG, and REXX.
MVS uses files called data sets that are organized in catalogs. The native encoding scheme of MVS is Big Endian EBCDIC, but MVS provides hardware-accelerated services to perform translation and support for ASCII, Little Endian, and Unicode.
One instance of MVS can occupy an entire physical system, a logical partition (LPAR), or a virtual machine under z/VM. Multiple MVS instances can be organized and collectively administered in a structure called a Systems Complex (Sysplex). Multiple Sysplexes can be joined via standard network protocols, such as TCP/IP or SNA. LPARs can also run other operating systems, such as Linux on zSeries, z/VSE, z/TPF, or z/VM
SNA
System Network Architecture (SNA) is the IBM proprietary networking architecture created in 1974. The architecture describes the structures, formats, protocols, and sequences for transmitting information through a network. It is a complete protocol stack for interconnecting computers and resources. SNA describes the protocol and is not a program. The implementation of SNA takes the form of various communications packages, such as VTAM, which is the mainframe package for SNA communications. SNA is used extensively in banks, financial transaction networks, and many government agencies. IBM continues to provide support for SNA, but the 3745/3746 communications controller is no longer sold by the IBM Corporation. IBM continues to provide hardware maintenance service and microcode features to support users. The VTAM (telecommunications access method) is also supported by IBM, as is the IBM Network Control Program (NCP) required by the 3745/3746 controllers.
VSAM
Virtual Storage Access Method (VSAM) is an IBM disk file storage scheme used in the OS/VS2 operating system and in the MVS architecture. VSAM comprises four access methods: Key Sequenced Data Set (KSDS), Relative Record Data Set (RRDS), Entry Sequenced Data Set (ESDS), and Linear Data Set (LDS).
VSAM records can be of fixed or variable length. VSAM records are organized in fixed-size blocks called Control Intervals (CIs), and then in larger divisions called Control Areas (CAs). CI size is measured in bytes, and CA size is measured in disk tracks or cylinders.
The IDCAMS program is used to manipulate ("delete and define") VSAM data sets. Custom programs can access VSAM datasets through data definitions (DDs) in Job Control Language (JCL) or in online regions, such as Customer Information Control Systems (CICS).
Both IMS/DB and DB2 are implemented on VSAM and use its underlying data structures.
VTAM
Virtual Telecommunications Access Method (VTAM) is the IBM software package that provides communications via telecommunication devices and users for mainframe environments. It is the implementation of Systems Network Architecture (SNA) for mainframes. VTAM is an API that controls communications in SNA networks. VTAM supports several network protocols, including SDLC and Token Ring.
The VTAM subsystem is controlled via commands issued through the system console or through control cards in the JES. VTAM is the SNA Services feature of Communications Server for OS/390. Communications Server for OS/390 also provides TCP/IP functions as part of the same software package. IBM continues to provide support for VTAM and SNA.
For additional information, visit:
http://www.microsoft.com/biztalk
http://www.microsoft.com/hiserver
BizTalk Adapters for Host Systems
http://www.microsoft.com/windowsserver/mainframe/analyst.mspx
Documentation on BizTalk Adapters for Host Systems
Related white papers: