Skip to content

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.