Page Comparison

There are 2 two types of Message Handlers in DataStage.

1. Project Level Message Handlers: These are installed in an application directory per Engine and

...

1. and aren't supported by MettleCI so should be migrated manually.
2. Job Level Message Handlers

...

1. : There is a MettleCI plugin to support their deployment only.  While MettleCI deploys Job Level Message Handler files from a Project's Git repository, it doesn't offer native check-in and deletion functions for them so they must be managed via command line Git.

Anti-Pattern

Message Handlers are not an asset of DataStage. See Note below for an explanation why.

In fact, they are an abnormal setting that disguises bad coding issues High-performing DataStage development teams rightly view message handlers as something that disguises poor coding or job design decisions. The reason they are used is that organizations They are most often found in organizations that mandate that Jobs should run without warnings but with little else to encourage their developers to remediate the root cause. As a result, the scheduling tools used Jobs are often setup to fail jobs set to Abort (e.g. via an After Routine) if they generate warning messages. Unfortunately, this usually oftem leads to developers becoming stuck in a situation where they don't have enough knowledge/tools/time to resolve the situation- especially those under pressure - applying message handlers to quickly get compliant and move on.

Organizations should refrain from using Message Handlers and should configure their Job Schedulers to be able to allow Warnings in exceptional circumstances. That way, high standards of development are generally maintained but in the unlikely situation that there is no alternative, Job Warnings can be allowed.

Message Handler Deployment Plug-In

Data Migrators have completed a new There is a Bamboo Plugin to support deployment of Job-Level Message Handlers (: dm-dsmsgh-plugin).

The new Plugin includes a task that will read all Message Handlers that follow a the "<Job Name>.msh" naming convention and "inject" them into the ISX file of the corresponding Job during deployment.  The updated ISX file can then be deployed like normal, resulting in both the Job design and Job-Level Message Handler ending up in the target DataStage instance.

The required changes to BIH are as followsIn order to use this MettleCI feature:

• All Job-Level Message Handlers in a particular DataStage Project will need to be added to the corresponding Git repository, alongside the existing ISX files.  These files need to be named following the "<Job Name>.msh" convention.
• Continuous Integration Build Plans and Deployment Environments in Bamboo Plans will need to be updated to execute the new "DataStage Message Handlers Task" immediately before the "DataStage Incremental Deployment Task".
• The For each Message Handler added to Git, the corresponding <Job Name>.isx jobs need to be checked in to Bitbucket again, in order to fool the Deployment plugin into promoting the Message Handler to Continuous IntegrationGit again. This is necessary to ensure that the subsequent CI Build Plan deployment (triggered by the check-in) will process the Message Handler as necessary.
• No changes to Bamboo Deployment Plans are Environment configuration is required.

How to Find the relevant Local.msh in the Information Server File System.

1. Let’s say you have For example: There is a Job in DataStage called “GR_ACCOUNTS_LOCAL"
2. Within the relevant Project filesystem, find the RT_SC<Job Number> directory that corresponds to the Job. The Simplest simplest method is to look in Directoruse Director to open up a log entry for the Job then get the "Job No." entry from that dialog box.
3. Within the RT_SC<Job Number> directory, find the Job-Level Message Handler config file (Local.msh)
4. Once found, copy and rename that file to GR_ACCOUNTS_LOCAL.msh and check it into Git alongside the existing ISX file
5. Once this file has been checked in, re-check in the corresponding Job. This ensures that automated deployments pick it up.
6. The (updated) Continuous Integration Bamboo Plan for the corresponding DataStage Project will be auto-triggered and must complete successfully. This will ensure that subsequent deployments to other environments (Test, QA, Production) will include Job-Level Message Handlers.

Changes to CI Plans

Continuous Integration Build Plans in Bamboo Plans will need to be updated to execute the new "DataStage Message Handlers" Task.

Once you have deployed the dm-dsmsgh-plugin plugin .jar to Bamboo, you will be able to add a 'DataStage Message Handlers' Task to an existing Continuous Integration Build Plan.

Ensure the new Task is immediately before the "Incremental DataStage Deployment" Task.

You can leave the Root ISX directory and Root message handler directory fields empty.

...