Multisystem routing services

To communicate with and transfer data between systems within your enterprise, z/OSMF uses z/OSMF-to-z/OSMF communication. That is, a z/OSMF instance communicates with other z/OSMF instances to collect information from or about the systems in your enterprise. To enable this capability, each system in your enterprise must be accessible by a z/OSMF instance. Typically, this requires deploying one z/OSMF instance in each monoplex or sysplex in your enterprise.

Although your enterprise can have multiple active z/OSMF instances, it is recommended that you make one instance the primary. The primary z/OSMF instance is the instance that:
  • Is the base for configuring the other z/OSMF instances in your enterprise.
  • Generates the Lightweight Third Party Authentication (LTPA) key that is used for single sign-on (if single sign-on is enabled).
  • Is used to perform all z/OS system management tasks in your enterprise, which ensures that the data for each z/OSMF task is centrally managed.
  • Acts as the client for all hypertext transfer protocol (HTTP) requests and drives the transfer of files between z/OSMF instances.

You can select any z/OSMF instance that is at least z/OSMF V2R1 with APAR PI32148 to be the primary instance. The remaining z/OSMF instances are referred to as secondary z/OSMF instances.

Example

For example, suppose your installation is configured similar to the installation depicted in Figure 1. The installation contains three sysplexes with a total of nine running systems. A z/OSMF instance is active in each sysplex, and your web browser is connected to the z/OSMF instance that is running on System 3 in Sysplex A. Thus, this z/OSMF instance is the primary instance and the z/OSMF instance running on System 6 in Sysplex B and System 9 in Sysplex C are the secondary instances.

Figure 1. Example sysplex and system configuration
Depicts an example sysplex and system configuration, and depicts the HTTPS protocol, which is used for communicating between z/OSMF instances.
To obtain information from System 6 in Sysplex B, the following actions are performed:
  1. A client application sends an HTTPS request to the primary z/OSMF instance.
  2. The primary z/OSMF instance routes the HTTPS request to the secondary z/OSMF instance in Sysplex B.
  3. The secondary z/OSMF instance processes the request and sends an HTTPS response to the primary z/OSMF instance.
  4. The primary z/OSMF instance returns the HTTPS response to the browser.
  5. The client application parses the response and extracts the appropriate information.

To route the request, the primary z/OSMF instance needs a system definition that specifies how to access the z/OSMF instance that is running on System 6 in Sysplex B and an HTTP proxy definition that specifies how to navigate the HTTP proxy server that is between the primary and secondary z/OSMF instances.

You can use the z/OSMF Systems task to add or modify the system and HTTP proxy definitions, and you can use the multisystem routing services to route the HTTPS request to the secondary z/OSMF instance and receive the HTTPS response. The remainder of this section describes the multisystem routing services. For information about the Systems task, see the z/OSMF online help.

Multisystem routing services overview

The multisystem routing services is an application programming interface (API), which is implemented through industry standard Representational State Transfer (REST) services. A set of REST services is provided for routing HTTPS requests to multiple systems in your enterprise. The multisystem routing services can route any HTTPS request that is supported by the z/OSMF REST services described in Using the z/OSMF REST services.

Table 1 lists the operations that the multisystem routing services provide.

Table 1. Operations provided through the multisystem routing services.
Operation HTTP method and URI path
Retrieve data from one or more systems
  • GET /zosmf/gateway/system?content=<http-content>
  • GET /zosmf/gateway/systems?content=<http-content>
  • GET /zosmf/gateway/group?content=<http-content>
  • GET /zosmf/gateway/sysplex?content=<http-content>
  • GET /zosmf/gateway/cpc?content=<http-content>
Update data for one or more systems
  • POST /zosmf/gateway/system
  • POST /zosmf/gateway/systems
  • POST /zosmf/gateway/group
  • POST /zosmf/gateway/sysplex
  • POST /zosmf/gateway/cpc
  • PUT /zosmf/gateway/system
  • PUT /zosmf/gateway/systems
  • PUT /zosmf/gateway/group
  • PUT /zosmf/gateway/sysplex
  • PUT /zosmf/gateway/cpc
Delete data from one or more systems
  • DELETE /zosmf/gateway/system?content=<http-content>
  • DELETE /zosmf/gateway/systems?content=<http-content>
  • DELETE /zosmf/gateway/group?content=<http-content>
  • DELETE /zosmf/gateway/sysplex?content=<http-content>
  • DELETE /zosmf/gateway/cpc?content=<http-content>
Authenticate with a secondary z/OSMF instance POST /zosmf/gateway/logon
Authenticate with an HTTP proxy server POST /zosmf/gateway/logon/proxy

Required authorizations

The user must be logged into z/OSMF. For information about client authentication in z/OSMF, see Authenticating to z/OSMF.

Content type used for HTTP response data

The JSON content type ("Content-Type: application/json") is used for HTTP response data. The following JSON object is used by all multisystem routing services for returning data and status about the requested operations. The attributes provided in the JSON object depend on the requested operation.
{
 "primaryAPIVersion":"primary-API-version",
 "systemsOutput":
   {
     "systemOutput":"system-output",
     "rc":"return-code",
     "error":{"msgid":"message-ID","msgtxt":"message-text"},
     "secondaryApiVersion":"secondary-API-version",
     "systemVersion":"
       {
         "zosNode":"zos-node",
         "zosVrm":"zos-level",
         "zosSysplex:"sysplex-name"
       }",
     "systemName":"system-name"
   },
 "numOfSystems":"total-systems"
}
where:
primary-API-version
Version of the multisystem routing services interface for the primary z/OSMF instance.
systemsOutput
Contains a separate response for each system to which the HTTPS request was sent. If the request was sent to multiple systems, the systemsOutput attribute contains an array of system responses.
system-output
Contains the response returned for a single system. A separate systemOutput attribute is included for each system to which the HTTPS request was sent.
return-code
Code returned by the system. The return code can be one of the following values:
OK
Success.
HttpConnectionFailed
The HTTPS connection failed. Typically, this error occurs when the system hosting the secondary z/OSMF instance is unavailable, the z/OSMF instance is not running, or a network error has occurred.
HttpConnectionTimedOut
The HTTPS request did not complete in the time allotted.
CertificateError
The certificate for the secondary z/OSMF instance is not trusted.
LoginRequired
The Lightweight Third Party Authentication (LTPA) token is not valid or has expired. You must submit a separate HTTPS request to authenticate with the z/OSMF instance.
InvalidLogin
The login credentials for the z/OSMF instance are not valid.
ProxyLoginRequired
Authentication is required by the proxy server.
InvalidProxyLogin
The login credentials for the proxy server are not valid.
FailedWithMessage
The request was successful; however, an internal error occurred with the secondary z/OSMF instance.
UnexpectedFailure
An unexpected error occurred.
error
If an error occurred with the request, the error attribute contains the message ID (msgid) and message text (msgtxt) for the message that was issued. Otherwise, this attribute is null.
secondary-API-version
Version of the multisystem routing services interface for the secondary z/OSMF instance.
systemVersion
Provides additional information about the system, as follows:
zosNode
JES2 multi-access spool (MAS) member name or JES3 complex member name that is assigned to the primary job entry subsystem (JES) that is running on the system.
zosVrm
Version, release, and modification level of the z/OS image installed on the system. The level has the format vv.rr.mm, where vv is the version, rr is the release, and mm is the modification level. You can correlate the returned value as follows:
  • 04.24.00 indicates z/OS V2R1
zosSysplex
Name of the sysplex where the z/OS® system is a member. The name is the value specified for the SYSPLEX parameter of the cross-system coupling facility (XCF) couple data set format utility.
system-name
Unique name assigned to the system definition.
total-systems
Number of systems to which an HTTPS request was sent.

Error handling

For errors that occur during the processing of a request, the API returns an appropriate HTTP status code to the calling client. An error is indicated by a 4nn code or a 5nn code. Some errors might also include a returned JSON object that contains a message that describes the error.

The following HTTP status codes are valid:
HTTP 200 OK
Success.
HTTP 400 Bad request
Request contained incorrect parameters.
HTTP 401 Unauthorized
Submitter of the request did not authenticate with the primary or secondary z/OSMF instance, or is not authorized to use the z/OSMF REST service.

If the user ID required to authenticate with the primary and secondary z/OSMF instances are not the same, submit a separate HTTPS request to authenticate with the secondary z/OSMF instances.

HTTP 404 Bad URL
Target of the request (a URL) was not found.
HTTP 500 Internal server error
Programming error.

Error logging

Errors from the multisystem routing services are logged in the z/OSMF log. You can use this information to diagnose the problem or provide it to IBM® Support, if required.

For information about working with z/OSMF log files, see IBM z/OS Management Facility Configuration Guide.