To enable data collection on IBM z/OS Connect EE and IBM WebSphere Liberty servers, update the server.xml file for every server that you want to access.
Perform the following procedures to update the server.xml file:
Update the feature manager section
Click here to expand...
In the feature manager section, add the relevant features for your server type:
Example
The following example shows the feature manager section of the server.xml file.
VIEW /home/bitgxt/wlp/servers/mjezapir/server.xml
Command ===>__________________________________________________________________
****** ***********************************************************************
000001
000002 <server description="api requestor">
000003
000004
000005 <!–– Enable features ––>
000006 <featureManager>
000007 <feature>restConnector–2.0</feature>
000008 <feature>batchSMFLogging–1.0</feature>
000009 <feature>zosconnect:apiRequester–1.0</feature>
000010 <feature>zosconnect:zosConnectCommands–1.0</feature>
000011 </featureManager>
Click here to expand...
To enable z/OS Connect EE servers to collect Version 2 of IBM SMF 123 records, you need to configure the audit interceptor in the server.xml file.
Add the following string to the file:
<zosconnect_auditInterceptor id="auditInterceptor" apiProviderSmfVersion="2"/>
Example
The following example shows the basic audit interceptor configuration:
000078 <!–– Audit interceptor configuration–smf ––>
000079 <zosconnect_auditInterceptor id="auditInterceptor" sequence="1"/>
000080 <zosconnect_authorizationInterceptor id="authInterceptor" sequence="2"/>
000081 <zosconnect_auditInterceptor id="auditInterceptor" apiProviderSmfVersion="2"/>
(Optional) To enable z/OS Connect EE servers to collect information about request and response headers, take the following steps:
Add request header information to the audit interceptor configuration:
apiProviderRequestHeaders="<requestHeaderName1>, <requestHeaderName2>, <requestHeaderName3>, <requestHeaderName4>"
Notes
Consider the following information:
- You can define a maximum of four request header names.
- You can define standard request header names (such as, accept or content-type ) or custom request header names. To define custom request header names, first map data to request header names in your API and deploy the API to the z/OS Connect EE server.
For z/OS Connect EE to capture request header information, ensure that the specified request headers are contained in the HTTP request.
Example:
curl -X GET --header '<requestHeaderName1>: <requestHeaderValue1>' 'http://sjsd:9999/CatalogManager/items?startItemID=10'
Add response header information to the audit interceptor configuration:
apiProviderResponseHeaders="<responseHeaderName1>, <responseHeaderName2>, <responseHeaderName3>, <responseHeaderName4>
Notes
Consider the following information:
- You can define a maximum of four response header names.
- z/OS Connect EE cannot capture standard response headers. You must map data to custom response header names in your API and deploy the API to the z/OS Connect EE server. Then you can define the response header names in the server.xml.
Example
The following example shows the audit interceptor configuration with request and response headers defined:
000078 <!–– Audit interceptor configuration–smf ––>
000079 <zosconnect_auditInterceptor id="auditInterceptor" sequence="1"/>
000080 <zosconnect_authorizationInterceptor id="authInterceptor" sequence="2"/>
000081 <zosconnect_auditInterceptor id="auditInterceptor" apiProviderSmfVersion="2"
000082 apiProviderRequestHeaders="accept,content–type"
000083 apiProviderResponseHeaders="retcode,respmsg"/>
Click here to expand...
Verify that the following items are set up:
- SAF authorization for z/OS Connect EE servers
- z/OS Connect EE keyring
Specify the following string in the ssl id tag:
clientAuthenticationSupported="true"
Example
<ssl id="DefaultSSLSettings" keyStoreRef="defaultKeyStore" clientAuthenticationSupported="true" sslProtocol="TLSv1.2"
trustStoreRef="defaultTrustStore" />
Define the authorization interceptor in the interceptor list:
Example
<zosconnect_auditInterceptor id="auditInterceptor" sequence="1" apiProviderSmfVersion="2"/>
<zosconnect_authorizationInterceptor id="authorizationInterceptor" sequence="2"/>
<zosconnect_zosConnectInterceptors id="interceptorList" interceptorRef="authorizationInterceptor, auditInterceptor"/>
Define the zosconnect_zosConnectManager tag as follows:
- Connect the MVJE PAS user ID to a group in globalAdminGroup,
- Set requireAuth to true.
- Set requireSecure to true.
Example
<zosconnect_zosConnectManager
globalInterceptorsRef="interceptorList"
globalAdminGroup="ZCONADM,MVJE"
globalOperationsGroup="OPR"
globalInvokeGroup="ALLZUID"
globalreaderGroup="ALLZUID"
setUTF8ResponseEncoding="true"
requireAuth="true"
requireSecure="true"
/>
httpEndpoint considerations
If the default httpEndpoint is bound to a VIPA address, a shared port, or a specific host name, MainView for Java Environments is unable to identify the replying server. This issue causes functions to fail or acquire nonsensical data.
You can resolve the issue by adding an additional httpsEndpoint that is unique to the server and host.
Example
The following example adds port 8385 as a new httpsEndpoint.
<httpEndpoint id="adminHttpEndpoint" host="*" httpPort="-1" httpsPort="8385" />
Tip
If you are experiencing PAS authorization issues, you can add the following line to the SAF security section in the server.xml:
<safAuthorization racRouteLog="ASIS"/>
This attribute enables the ICH408I message, which identifies the blocked resource.