Showing posts with label app connect enterprise. Show all posts
Showing posts with label app connect enterprise. Show all posts

Monday, 12 October 2020

Building IBM ACE Bars using Azure DevOps and a Windows Build Server

For the last few months I have been looking at the most appropriate way to build ACE artefacts. This ranges from what makes good practice for ensuring consistency, what allows the best governance procedures to be followed and what is the best way to isolate the build and deploy of the artefacts?

One of the more common pipeline tools that is being used is Azure DevOps and so I've been playing with the mqsicreatebar, mqsiapplybaroverrides and mqsideploy commands in IBM ACEv11. The following are steps I wanted to achieve to get deployable units in ACE:

  • Build a Base BAR file
  • Apply environment specific overrides to the Base BAR to create an environment BAR file
To complete the build process we need to be able to run ACE commands. To do this we could use an external Server but when using a Windows machine there are certain ways these commands might be run. 

The following are some tips on how I completed the steps using Azure DevOps and Windows in my demo building scenario.

Method of Execution

Having decided to produce a script to be run on the Windows machine the first decision was whether to run as a batch script, bash script or PowerShell. 
  • PowerShell is the Azure Cloud preferred method and comes with the PowerShell pipeline
  • Batch files are out of the box, well understood by most and so likely to be easily supported
  • Bash scripts are cross platform, easily portable and possibly better understood than batch scripts
In the end I chose bash because of the portability and ability to move across Cloud and Operating Systems with more ease and increases the number of people who can edit and support the scripts in future.

Running ACE Commands on Bash on Windows

Bash is not currently native to Windows machines and as such you have to run a bash environment on the Windows system. This will usually be Git Bash so to run in the Build pipeline in Azure using the command line task:
“C:\Program files\Git\bin\bash.exe” myscript.sh

 In order to run ACE commands, the ACE profile needs to be setup using the mqsiprofile command. In the Build pipeline in Azure using the command line task, run the following:

“Drive:\InstallPath\server\bin\mqsiprofile” && “C:\Program files\Git\bin\bash.exe” myscript.sh

Check the format of each ACE command 

It's important to check the format of each of the commands in ACE as some of the command are already executable in shell e.g. cmd format and do not need the file path specificying in the bash script, others are in BAT format so need the full path specifying. One example of this and specific to our needs is the mqsiapplybaroverrides command which needs the .bat extension name when being called in the bash script and also needs the full path to the file.

Passing Azure Variables to the Script

Azure variables need to be passed to the script via the command line task. Azure uses the following format to reference existing variables $(myVariable). Variables can be passed in using the Variables tab e.g. appName (to specify which to build) or predefined Azure variables e.g. System.ArtifactsDirectory

Example buildACE.sh $(appName) $(System.ArtifactsDirectory)

#!/bin/bash
appName=$1
buildAddress=$2
mqsicreatebar -data ${appName} -b ${buildAddress}/${appName}_Base.bar -a ${appName} -deployAsSource
drive:/installPath/server/bin/mqsiapplybaroverrides.bat -b ${buildAddress}/${appName}_Base.bar -p ${appName}/dev-overrides.properties -o ${buildAddress}/${appName}_DEV.bar -r

The following example will take the application being built and the build output location (Artifact) as parameters which are used in the bash script. 

As you can see the mqsicreatebar can be ran without specifying a path because we have the mqsiprofile set, but the mqsiapplybaroverrides needs thee full path to the batch file defining.

The output from the above script would be a base bar and a dev bar for the application name supplied in the Azure Build. Further scripting can be implemented to produce BARs for more environments.

Saturday, 20 July 2019

Connecting to db2 with JDBC Driver in App Connect Enterprise (ACE)

Whilst recently connecting to an IBM DB2 through an App Connect Enterprise (ACE) bar file following (parts of) this tutorial on developer works - https://developer.ibm.com/integration/blog/2019/01/15/connecting-integrations-to-jdbc-endpoints-on-app-connect/ I hit a couple of issues due to using different naming standards and from (naughtily) plucking specific parts from the article but not following it properly. 

I have been using IBM Cloud Private where both an ACE helm chart (11.0.0.4) and DB2 are both deployed with different names and data models than those defined in the example. If, like me, you bypassed parts of the example here are some issues you might have seen.

1. In containerised ACE deployment the JDBC Driver JAR should be loaded into the project to be packaged with the bar (as decribed in the article above)

a.    In the ACE Toolkit go to Window -> Show View-> Java
b.    Drag and drop the db2jcc4 JAR file into Project window
c.    Right Click (double finger click on the MAC) on the Java Project Folder and select Properties -> Java Build Path -> Click Add JARs -> Select db2jcc4 jar file -> Click OK
d.    Ensure the Java Project is included in the bar file
e.    Ensure “User JAR files that have been deployed in a .bar file” is set to true in the JDBC Policy as defined in the tutorial and that the policy is included in the bar file build

2. After the deployment there was still an error that persisted;
"com.ibm.broker.classloading.JarsURLClassLoader.findClass(JarsURLClassLoader.java:104)" 
I was able to find greater debug logs in ICP in the following file, in the following file;
/home/aceuser/ace-server/log/integration_server.<servername>.events.txt
6231E: An error occurred in node: Broker 'integration_server'; 
Node Type 'DeleteProducts_JavaCompute Exception details:  message: com.ibm.db2.jcc.DB2XADataSource stack trace:  java.net.URLClassLoader.findClass(URLClassLoader.java:610) \ncom.ibm.broker.classloading.JavaResourceClassLoader.findClass(JavaResourceClassLoader.java:180) \ncom.ibm.broker.classloading.SharedClassLoader.findClass(SharedClassLoader.java:209) \njava.lang.ClassLoader.loadClassHelper(ClassLoader.java:937
 The error looks like the jar has not been correctly loaded, to check we can;

  • Looking in the bar file on the toolkit in the ‘Manage’ tab which should show the jar file in the REST API Application.
  • Convert the bar file into a zip and unzip it to see the files inside where the jar should be visible.
If that all looks good, next you should check the JDBC connection in the Java Compute Node.
Connection conn= getJDBCType4Connection("BLUDB",                                      JDBC_TransactionType.MB_TRANSACTION_AUTO);
The example makes it look like BLUDB should match the name of the policy since the policy, database name and connection definition are all the same. The error also doesn’t point very well at what the issue is.

The connection should refer to the Database name being connected to. In my personal view, I would follow the example and call the policy the same name as the database being connected to which can be referred to in getJDBCType4Connection.


Hopefully this has helped you with your development!