Design Overview
The ZMF/Jenkins integration implementation consists of a number of loosely coupled services. This section gives a brief overview of the main components:
-
Events
Describe something that has occurred in ZMF. For example, Package Create.
-
Event Variables
Standardized variable names used throughout the various services.
-
Event Source
The source of a ZMF Event.
-
Event Clients
Program to forward a specific event from an Event Source to REST Services
-
Event Subscribers
An entity represented by a URI that subscribes to one or more ZMF Events.
-
REST Services
REST services provides a REST API for Change Man ZMF Services. This is a true REST API where each transaction connects to ZMF, processes the request, disconnects from ZMF and returns the result to the client. Also processes events sent from the event clients. Handles sending events to multiple subscribers and custom response handling.
-
ZMF REST Services Extensions
A client side wrapper for ZMF REST API’s. This implements support for bulk client transactions and helper methods that demystify ZMF data structures.
-
Jenkins SCM Plugin interface
A Jenkins Plugin to provide ZMF SCM functions in pipeline scripts.
-
Security Considerations
Security Considerations for ZMF / Jenkins Environment.
-
Events
The ZMF Package/Component lifecycle may be described by a series of Events. This section identifies the published events as well as the event source. The following sources generate events depending on the type of processing:
-
SKEL
ISPF Skeletons customize batch processing in ZMF. Batch processes generate Events by imbedding the appropriate Event Skeleton (An Event Client).
-
HLLX
Exit routines in ZMF that provide consistent processing for multiple client types. These routines generate Events by calling the Event Client.
-
LOG
ZMF writes Log records at many points during processing. A post-processing routine sends the records to REST Services.
The table below lists the currently defined ZMF Events (Taken from the existing ZMF Event Log) A review of ZMF Services is required to determine additional event points.
Events with an Asterisk are not processed. The SKEL/HLLX/LOG columns indicate if this source is capable of generating the event. (values are Yes/No/Maybe).
| Event | Event Source | Description | ||
|---|---|---|---|---|
| SKEL | HLLX | LOG | ||
| 00 | N | N | Y | major - initialize/terminate |
| 01 | Y | Y | Y | Backout Package |
| 02 | Y | N | Y | Install Package |
| 03 | Y | N | Y | Temporary Change Cycle |
| 04 | Y | N | Y | Distribute Package |
| 05 | N | N | Y | Unauthorized Member Access |
| 07 | N | N | Y | Generate Package Information |
| 08 | N | N | Y | Delete Package (Physical Delete) |
| 09 | N | M | Y | Update Application Information |
| 10 | note1 | Y | Y | Revert Package |
| 11 | N | N | Y | Update Global Information |
| 12 | Y | N | Y | Activate Component |
| 13 | N | N | Y | Memo Delete Package |
| 14 | N | N | Y | Undelete Package |
| 15 | Y | N | Y | Baseline Ripple |
| 16 | Y | N | Y | Reverse BAseline Ripple |
| 18 | N | N | Y | Age Installed Package |
| 20 | N | Y | Y | Approve Package |
| 21 | N | N | Y | Re-sync Calendar |
| 22 | N | N | Y | Age Staging Libraries |
| 23 | note4 | N | Y | Backout Release |
| 24 | note4 | N | Y | Install Release |
| 25 | note4 | N | Y | Distribute Release |
| 26 | N | N | Y | Delete Release |
| 27 | note4 | N | Y | Revert Release |
| 28 | N | N | Y | Approve Release |
| 29 | N | N | Y | Reject Package |
| 30 | N | Y | Y | Reject Package |
| 31 | N | N | Y | Memo Delete Release |
| 32 | N | N | Y | Undelete Release |
| 33 | note4 | N | Y | Baseline Release |
| 34 | N | N | Y | Install Release Aged |
| 35 | N | N | Y | Block Release |
| 36 | N | N | Y | Unblock Release |
| 37 | N | N | Y | Create/Update Release |
| 38 | N | N | Y | HLLX Administration |
| 39 | N | N | Y | HLLX Commands |
| 40 | N | Y | Y | Freeze Package |
| 42 | N | Y | Y | Selectively Unfreeze Package |
| 43 | note2 | note2 | Y | Demote Component |
| 44 | Y | Y | Y | Demote Package |
| 45 | Y | N | Y | Promote Release Area |
| 46 | Y | N | Y | Demote Release Area |
| 48 | Y | Y | Y | Promote Package |
| 49 | note2 | note2 | Y | Promote Component |
| 50 | Y | Y | Y | Audit Package |
| 51 | N | N | Y | Alter Audit Return Code |
| 52 | Y | N | Y | Audit Release Area |
| 53 | N | N | Y | Approve Release Area |
| 54 | N | N | Y | Reject Release Area |
| 55 | N | N | Y | Block Release Area |
| 56 | N | N | Y | Unblock Release Area |
| 57 | Y | N | Y | Submit package audit Auto resolve |
| 58 | Y | N | Y | Submit Release Audit Auto Resolve |
| 60 | N | N | Y | Lock package before promote |
| 62 | N | N | Y | Unlock Package after promote |
| 64 | N | Y | Y | scratch a component |
| 66 | N | Y | Y | rename a component |
| 67 | Y | Y | Y | Relink component |
| 68 | N | N | Y | copied a component |
| 69 | N | N | Y | Recompile Component |
| 70 | N | N | Y | file tailoring started |
| 71 | N | N | Y | file tailoring failed |
| 72 | N | N | Y | file tailoring completed |
| 78 | note3 | Y | Y | Checkin to release area complete |
| 79 | N | N | Y | Retrieve from release area complete |
| 80 | N | Y | Y | Create Package |
| 81 | note2 | note2 | Y | Check component into release area |
| 82 | note3 | Y | Y | Checkout Component |
| 83 | N | N | Y | potential checkout conflict |
| 84 | N | Y | Y | Stage Component |
| 85 | N | N | Y | overlay previous module |
| 86 | N | Y | Y | delete component from package |
| 87 | note3 | Y | Y | Checkout Component from release |
| 88 | N | Y | Y | copy forward package |
| 89 | N | N | Y | Retrieve component from release |
| 90 | N | N | Y | monitor limbo and internal scheduler |
| 91 | N | N | Y | Update Release Global Approvers |
| 92 | N | N | Y | Update Release definitions |
| 93 | N | N | Y | Update Release Applications |
| 94 | N | N | Y | attach package to release |
| 95 | N | N | Y | detach package to release |
| 96 | N | N | Y | link a release (RLM function?) |
| 97 | N | N | Y | unlink a release (RLM function) |
| 100 | Y | Y | N | Pre-Build |
| 101 | Y | Y | N | Build |
-
note1: Depending on whether you are working with an ALL or DP/P sites there may not be a batch job associated with a package revert. The skels notification of this event takes place where a batch job is used.
-
note2: These events may apply to many thousands of components in a single action. It makes no sense to call the REST server for each component. The package (or area) level action event is supported and any process driven by the package level event can use ZMF REST services to query the package for individual components should that be necessary.
Note
The individual component events will continue to be written to the log for post-processing.
-
note3: A batch job is only involved, and this event emitted via the skels notification, if the action is performed in batch mode.
-
note4: An ERO release ties together one or more ZMF packages. When you do anything at the back end of a release lifecycle (e.g. install a release etc.) you are actually causing the same action to be taken for the group of packages that make up the release. So each of these packages will already be generating standard (i.e. base ZMF) events for these actions (e.g. 02 - Install package). For these events, you should use the 'log' emitted event.