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.
- 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.
- A client application sends an HTTPS request to the primary z/OSMF instance.
- The primary z/OSMF instance routes the HTTPS request to the secondary z/OSMF instance in Sysplex B.
- The secondary z/OSMF instance processes the request and sends an HTTPS response to the primary z/OSMF instance.
- The primary z/OSMF instance returns the HTTPS response to the browser.
- 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.
Operation | HTTP method and URI path |
---|---|
Retrieve data from one or more systems |
|
Update data for one or more systems |
|
Delete data from one or more systems |
|
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
{
"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"
}
- 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.
- 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.