Page Comparison

 As previously highlighted, the very nature of IBM’s tools for managing Job Level Message Handlers in Information Server means any automation solution for them will be at risk of permanent regression with future IBM Fix Packs and Releases. Even in the absence of such automation challenges, we suggest the general situation with Job Level Message Handlers ought to trigger customers to reconsider their use (or at least modify the tolerance of Warning Messages by dependent systems) and refactor accordingly.

A new plugin to "inject" message handlers into existing ISX files has been created and tested

I'm happy with this and its verified to work on DS v11.5 and v11.7
This is available as "dm-dsmsgh-plugin-1.0-1.jar" in artifactory
There is also a new incremental deployment plugin (v1.0-99) which will also need to be installed
This updated plugin will deploy ISX files with binaries
The remaining steps is to document the approach for ANZ.
At a high level, the process is as follows:
1. Update the dm-dsdeploy-plugin. This will have to be done after/with the new licensing plugins have been deployed
2. Install the new dm-dsmsgh-plugin (also requires licensing)
3. All existing job level message handlers need to be manually checked into GIT. This requires extract the "Local.msh" files for each job and renaming them as "<job name>.msh" in the GIT repo. When this has been done, these files will sit along side their related .ISX files in the datastage folder in GIT
4. CI plans will need to be updated with the DS Message Handler Task. This needs to run prior to Incremental Deployment Task. Both ISX and MSH location parameters should be set to "datastage"
5. Job done. The ISX artifacts used during deployments will already include the message handlers, so no further changes are requiredAdd .msh files have to be added manually to Git
The .msh file names need to match Datastage job names
Mention that .msh usage is an anti-pattern and the current approach might stop working in future versions (tested in IIS 11.5)