I have recently worked on architecting an integration solution involving BizTalk reading XML off an AS/400 data queue. Now this was my first foray into the world of IBM and I found the learning curve to be rather brutal considering I had to learn the nuances of a new operating system in addition to uncharted programming models using BizTalk Server and HIS (Host Integration Server). In this blog post I will discuss the options available to implement such a solution and factors to consider when choosing which option is the right fit (like most integration problems, the answer to this question is “it depends…”). I won’t discuss the actual technical implementation which I will save for another day, and I will aim for simplicity rather than absolute technical accuracy/thoroughness given the overwhelming amount of information to take in and my relative newness to the IBM experience. That said, if any AS/400 or HIS gurus think I have oversimplified any concepts too much (or have misrepresented them altogether) then feel free to comment on the post.
Data queues are a native lightweight queuing technology built into the OS/400 operating system and provide an efficient means of asynchronous or synchronous messaging between applications in an AS/400 environment (see this post for some advantages of using data queues). Data queues aren’t to be confused with Websphere MQ which is another more robust and fully featured queuing technology that requires additional licensing and isn’t built into the operating system. CL (Control Language which is the native scripting language on AS/400s) commands are provided out of the box that allow for interaction with data queues and can be used in COBOL/RPG programs or DB2 stored procedures.
HIS is the Microsoft product which enables integration of windows applications with midrange and mainframe environments. HIS licenses are combined with BizTalk Server licenses so is the obvious choice of tooling for the aforementioned problem given that a BizTalk Server license was already owned by the client.
There isn’t currently any means of directly integrating BizTalk with OS/400 data queues using any of the native BizTalk adapters or those provided by HIS without some form of a wrapper in the AS/400 environment. As previously mentioned the CL commands used to interact with the data queues can be utilized in COBOL/RPG programs or DB2 stored procedures, both which can serve as wrappers which BizTalk can interact with using different programming models provided by HIS.
The first option of using a COBOL/RPG program is a more programmatic approach. The BizTalk Adapter for Host Applications (BAHA) adapter (which is packaged with HIS) can be used to call on the program and return the response using an underlying API technology called DPC (Distributed Program Calls) that allows for non AS/400 applications to interact with an AS/400 environment over TCP/IP.
From a BizTalk developers perspective this involves creating HIS metadata in a TI (Transaction Integrator) project in Visual Studio based on the COBOL/RPG program (this can either be done manually or by pointing a wizard at the program saved in a text file) which will generate a DLL that you must have the adapter reference, as well as XSD schemas which you can use in your BizTalk project to represent the request and response signature of the program in question.
There are a few considerations when using the BAHA adapter in tandem with DPC.
- DPC only supports client/windows initiated processing which is to say that you can only use the above pattern in a send port. If you want to implement this pattern in a polling fashion then you will need to use the scheduled task adapter or a similar solution.
- DPC supports a limited number of input and output parameters (35 in total in any combination) and does not support result sets.
- DPC enforces a size limit on your request/response messages in that they can’t be larger than 32kb.
- DPC requires that the OS/400 version is at least release 4 version 1 (I have been assured by a clued in colleague that this is a very old version so shouldn’t be a problem at most sites) and that the DPC server daemon has been turned on (which should be the case if there are currently any windows applications that make API calls to the AS/400 environment).
- HIS provides a pretty nice emulator tool that allows you to emulate your COBOL/RPG programs on the AS/400 environment which makes it easy for a developer to generate HIS/BizTalk components and test them without actually having access to the AS/400 environment, they only need a copy of the program’s source code.
- Security can be applied on the COBOL/RPG program to restrict it to specific users.
The second option is to use DB2 stored procedures to wrap/expose the interaction with the data queue and use the DB2 adapter (which is packaged with HIS) to call on the stored procedure. Now many non-IBM developers might be up in arms regarding this option (as I was initially) thinking that a database stored procedure should not be used to expose application logic. Once again things are a bit different in the IBM world where the DB2 database is a native (you’ll notice I have used this word a lot today) part of the operating system as are commands to interact with the database, and stored procedures are a very common medium for exposing application logic, and in fact any ILE (Integrated Language Environment) program (CL, COBOL, RPG, C and C++) can be exposed as a stored procedure.
From a BizTalk developers perspective the experience of dealing with the DB2 adapter is similar to that when dealing with other databases in that you use the add adapter metadata wizard to generate XSD schemas representing the request and response signatures of your stored procedure and send the appropriate messages to the DB2 adapter.
There are fewer technology considerations when using the DB2 adapter to call on stored procedures.
- The DB2 adapter supports receive operations (via polling) as well as send operations thus removing the need for building custom polling mechanisms.
- The DB2 adapter returns its responses in the form of result sets and doesn’t enforce a size limit.
- Security can be applied on the stored procedure to restrict it to specific users.
So what are the appropriate questions to ask when deciding which technology to use to solve such a problem?
- Does the functionality already exist in the AS/400 environment either in the form of a COBOL/RPG program or a DB2 stored procedure? If so then it might be preferable to go with the status quo.
- If the functionality doesn’t already exist then do the AS/400 developers have a preference or any architectural guidance that they normally apply to such choices? How do currently deployed non-AS/400 applications interact with AS/400 components? Are there any COBOL/RPG programmers available?
- Does BizTalk need to fetch result sets or just a single value? Is the return message larger than 32kb?
- What version of OS/400 is currently deployed and is the DPC server currently activated? If not then is the client open to activating it?
- Does the solution require polling which is much more easily implemented with the DB2 adapter?
At this stage I am unable to qualify whether there is any difference in responsiveness between the two adapters and programming models, and have not found any definitive sources that have carried out such a comparison. If there a difference then this would of course be a major factor in the decision as well (especially if the solution has any requirements around low latency). I will add a comment to this blog post when I do manage to qualify this and please do feel free to add your own comments if you have any past experience around this.
I will look to supplement this blog post with practical examples in the future. Can anyone think of any additional factors that might influence such decisions or of any other options to implement this solution using BizTalk Server?
Hi
Sorrry, I’am danish and it is very rare that I write in English. I write to you because, it is very rare that any are working with things. And my be it can help to learn what we did in a almost similar situation. You are free to use what I wrote below.
Some time ago I spend a lot time using HIS, WebSphere MQ and BizTalk to call a mainframe and CICS. There are som differences between AS/400 and Mainframe, but the things you descripe are very similar.
It is long time ago(2006), and back then BizTalk and HIS was to separate products.
We inherited existing infrastructure and logic on the Mainframe with about 200 CICS call, that we had to reuse. All so the client where mainly Web applications, implemented in Java, .Net and Domino, that wanted to call the Mainframe. Because of the clients high demands for low latency, we ended up not using BizTalk. We chose to use HIS Transaction Integratror (TI), and expose it as WebService hosted by IIS, with a little bit off custom code. The contract off the webservice was COBOL copybooks imported, the way you descripe in your blog. We did some tooling, and wrote a howto, and in the Mainframe developers created the webservices, and sometime even tested with Soap UI. It was a huge success. And got the mainframe developers away from there green screen into Visual Studio . Off because we had to live with 32 kb inout, but most off the time it was no problem, and something the mainframe developers where used.
A few years later we wanted the mainframe and CICS to call Webservices implemented in Java and .Net. At the time IBM had implemented so the mainframe could calls webservices, but I do not know why we did choose to use it. Below I would descripe what we used.
The company bought a product, such that the mainframe using Cobol, could work with XSD and XML. Very similar to xsd.exe from Microsoft. We ended up using the droping some xml on WebSphere MQ, BizTalk picking it up and doing some transforming off the message, BizTalk calling the webservice, BizTalk getting the response and transforming to Mainframe xml, and returning the message to the response queue. The development model was very hard and time consumeing. First the mainframe developers was not used to working with XML. And the mainframe xml did not gave much value, because we still had to transform the message in BizTalk.
I spent almost 2 years with doing mainframe integration, using HIS, BizTalk, .Net and WebSphere MQ. Because fore me the mainframe are very strange, it is vital that you some great people on there side, that have a understanding for .Net, Xml and so on. And you have to understand there platform, and what they can do and not do. I spend countless hours, debugging mainframe code, looking into the green with a mainframe developer.
LikeLiked by 1 person
Hi Claus,
Thank you for sharing your insight and I am glad to hear that the project was met with success. I will definitely keep your comments in mind in the future when I have to integrate with mainframes.
Cheers
Johann
LikeLike
Hi Claus,
Thank you for sharing your experience and insight with this architecture. I am working on a design right now with BizTalk 2013 and would like to use data queues. I am very curious if you are willing to share some information on the solution you build using the is architecture. We are going to have a requirement for poll the data queue for messages coming back from the AS/400. Based on the information you provided it looks like the DBStored Procedure would be the best approach for us. I have also found some information that that data queues also support ADO. Do you have any experience with using ADO in this architecture.
LikeLiked by 1 person
Hi Greg,
do you have any update about the architecture adopted?
Do you started developing some flows?
Regards,
Max
LikeLike
Hi Maxlisi,
This isn’t Greg’s blog so chances are that he is not seeing your comment. I haven’t delved back into this space since I wrote the original blog post, but what I can tell you is that stored procedures worked well for us in my scenario.
Cheers
Johann
LikeLike
Hi Claus,
Thank you for sharing your experience and insight with this architecture. I am working on a design right now with BizTalk 2013 and would like to use data queues. I am very curious if you are willing to share some information on the solution you build using the is architecture. We are going to have a requirement for poll the data queue for messages coming back from the AS/400. Based on the information you provided it looks like the DBStored Procedure would be the best approach for us. I have also found some information that that data queues also support ADO. Do you have any experience with using ADO in this architecture.
LikeLike