Showing posts with label windows. Show all posts
Showing posts with label windows. 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.

Monday, 28 November 2016

IBM MQ Exits - Good To Knows

I recently co-created a security and message exit. The main code was written in C for a linux machine. The exit was later needed for a windows machine. Here are some of the things I learnt when migrating from a linux exit to windows and reminders to myself for the future.

- Windows exits are compiled into dlls.

 - Whilst unix machines will allow you to compile C using gcc with declarations made at will throughout the code. It is integral that all these declaration are made at the start of each function for the windows platform.

- Another key thing learnt was that whilst in many examples you may see exporting functions in windows in the following form "__declspec( dllimport )" or by declaring "C extern". Being new to security exits on windows I hadn't realised that the external functions needed to be declared in a definition file or a .def in the following format.
"EXPORTS
ExitName"

- Exits names are case sensitive.

- Whilst Security Exits are needed both on the sender and receiver channels, message exits are only required on one of the channels.

It is highly recommended that anyone creating Exits have a knowledge of both MQ and the operating system/coding language being used and takes the time to understand the implications of the code being used and the security issues that may arise.

There is a useful resource on the IBM Knowledge centre for compiling exits which can be found here:
http://www.ibm.com/support/knowledgecenter/SSFKSJ_7.5.0/com.ibm.mq.dev.doc/q028160_.htm