TriZetto Hosting has a framework in place for executing batch jobs – and that framework is called the Hosted Batch Architecture or HBA for short. So if you are a TriZetto Hosting customer, and are writing custom code to extend/enhance the core functionality of
QNXT or Facets, you will come to a cross roads where you will need a job created to execute this custom code. And this is where the HBA comes into play. You will have to make sure your job is HBA compatible.
Before I get into what it means to be HBA compatible, I’d like to bring up the benefits the HBA provides us. The HBA provides a common look and feel for the execution and supportability of all jobs. This is a very important principle in custom development practice – keeping things consistent and the same. This means that all jobs will be kicked off the same way, they will use the same resources like I/O and database connections, and in the event that an error occurs, errors will be handled in the same manner. This is a very powerful benefit for TriZetto customers in my opinion. This reduces the burden and the cost of troubleshooting problems when they arise.
The HBA in it of itself is a “black box.” So I can not really tell you what the HBA is. The TriZetto documentation refers to is a framework, so that is what I call it here. From a customer’s point of view, I can share with you that jobs can be configured using XML, and that you can use VB Script to extend the capabilities of the HBA if the need arises.
Creating jobs that are HBA compatible
Note: this section is entirely QNXT specific, and speaks to version 4.51 of the HBA
In a
previous post, I discussed customizing
QNXT using the Custom Database. Once you have a Custom Database setup, you will need custom code to take various read and write actions against that database. A common approach is to write this custom code into
SQL Server Integration Service (SSIS) Packages. SSIS allows you to extract, transform and load data in and out of SQL Server.
Within an SSIS Package you define Connection Managers for any type of resource that will be consumed or published by the SSIS Package. For example, you will need Connection Managers for database connections, file system locations (like an /input or /output folder for example), SMTP and any other resource that will be part of the workflow of the package. A common practice in SSIS development is to place the values of these resources into a configuration file called .dtsConfig, and bind these configurations in at runtime. This way, if you have varying configurations depending on which environment (development, test or production) the package runs in, you don’t have to change code in the package to deploy to these environments.
In order to use a configuration file, you have to define Package Variables within your SSIS package. And use these Package Variables when creating Connection Managers so that resource names are never hard coded into the package. At run time, when the configuration file is bound in, the Package Variables are populated with the appropriate values for that environment, and the Connection Managers are ready to be consumed by and published to.
With the HBA, you employ a similar practice. The key differences are that:
(a) The configuration file is not a .dtsConfig. Instead it is a proprietary TriZetto file called Common System Properties. And if any local configurations are needed, there is a separate configuration file called the HBA Wrapper also referred to as the job XML
(b) The Package Variables must be placed within an HBA namespace
TriZetto provides an HBA Development Guide which details all of the particulars of how to build HBA compliant SSIS Packages, which includes, among other things the Package Variables you must use. So becoming HBA compatible means employing these practices in your custom code.
Recommended Reading
If you are a TriZetto customer and are looking to familiarize yourself with the HBA, in addition to reading the HBA Development Guide, I recommend you also request information about:
- Common System Properties - this should will come in the form of a list of variables and their meaning
- HBA Wrapper Dev Guide - this has a list of commands you can execute inside of the HBA. For example, there are command for file manipulation like fileDelete() and fileCompress().
- Client Specific - you can enhance the functionallity of the HBA with VB Script be creating a Client Specific VB file that is imported into the HBA
- Auto Date Parameters - there are a series of data variables that are predefined and available to you in the HBA. For example, there is a date variable that always returns the first date of the current quarter, or the last day of the month
Stay Tuned ...
In a future post, I will discuss a unique challenge that you have to solve with respect to HBA. Since the HBA is only available in your hosted environments, you need a mechanism to unit test your code to make sure that you are consistently creating HBA compatible custom code.