BizTalk Adapter for Host Applications (BAHA) is a
subset of the BizTalk Adapter for Host Systems. BAHA provides BizTalk
Server with the extensibility needed to access legacy systems. It
leverages the Transaction Integrator capabilities by supporting
Windows-initiated processing scenarios and therefore supports all the
programming models for mainframe and AS/400 access. From a BizTalk
configuration perspective, it provides a solicit-response adapter that
targets remote environments defined in the TI Manager. Every time the
BAHA receives an XML instance to be sent to a mainframe, the BAHA
Runtime compares the received instance against its corresponding BizTalk
schema and transfers the data to Transaction Integrator. From there,
Transaction Integrator is responsible for sending the data to the
mainframe, receiving the response, and then returning the data to the
BAHA.
The BAHA Runtime maps the
mainframe datatypes and data back to .NET datatypes, creates the XML
response document, and passes the data back to the Messagebox through
its corresponding port. From a send port configuration perspective, the
Host Type property allows you to select a TI remote environment—your
mainframe region. The Allow Advanced Override and Allow Security
Overrides properties allow you to manipulate the TI Client Context
object. The Persistent Connections property allows you to create
persistent connections when working with batches of messages. We
recommend the use of persistent connections to improve the performance
and also to maintain the state in the server. The SSO Affiliate
Application property allows you to use either a specific SSO Affiliate
Application or the settings of the TI remote environment selected in the
Host Type property. Figure 1 shows the available properties for the BAHA solicit-response port.
As we pointed out earlier,
BAHA relies on the Transaction Integrator to access legacy systems. The
setting that you need to set up in the Transaction Integrator object to
generate a BizTalk schema is its Type Restrictions property. You have to
set its value to BizTalk Adapter for Host Applications. The purpose of
this Type Restriction is to prevent the TI client application from using
conventions unsupported by BizTalk Server. However, it doesn't stop the
client application from calling the assembly directly from any other
Windows application. Figure 2 shows the TI Assembly Properties window highlighting the type restrictions available.
Once you have saved your TI
changes in the Visual Studio project, an XML Schema Definition (XSD)
file with the definitions for the request and response messages that
BAHA will use will be generated. Afterward, you will need to import the
XSD file into your BizTalk Server project. By doing so, when you deploy
your BizTalk application, you will have the new BizTalk schema available
in the schemas directory in the BizTalk application. One of the
benefits of this approach is that you if you need to populate fields in a
TI object that has a large amount of fields, you can use a BizTalk
Server map and populate the input fields easily from an orchestration.
Nonetheless, I recommend you ensure that you handle the TI object
versions properly, so the XSD definitions you use in your BizTalk Server
project always reflects the latest changes/updates you may have
performed to your TI object definition and deployed to TI Manager. Figure 3 shows a sample TI XSD file imported in a BizTalk Server project.
Figure 4
shows two BAHA nodes connected to an enterprise SNA Gateway. Remember
that every BAHA node should have installed and configured Transaction
Integrator to access the SNA Gateway. A SQL Server is required to work
with Transaction Integrator, so port 1433 should be opened, and remote
access should be enabled as well.
