5 Testing and Troubleshooting

After you deploy the connector, you must test it to ensure that it functions as expected. This chapter contains information on the following types of testing:

Connectivity testing: All message transport layers have a dependency on open ports, allowing application data to be to be passed between applications and between systems. This test checks for open ports on the mainframe system from the Oracle Identity Manager system. Both IBM MQ Series and TCP/IP message transport layers depend on open ports to communicate.
Provisioning Testing: This type of test involves using Oracle Identity Manager for provisioning or de-provisioning one of its users or organizations with a target resource. In other words, Oracle Identity Manager is the starting point of the connector, and the target resource is the end point.
Reconciliation Testing: In this type of test, you reconcile Oracle Identity Manager with the target resource. In other words, the target resource is the starting point of the connector, and Oracle Identity Manager is the end point.

This chapter contains the following sections:

Port Connectivity Testing
Running Test Cases
Troubleshooting
Performance Testing

Port Connectivity Testing

This section discusses open port testing for the connector. Testing of open ports is done on the Oracle Identity Manager server system.

The following tests assume that the test will be conducted on the Oracle Identity Manager server, with required ports open to the mainframe.

For IBM MQ Series messaging, the standard port is 1414. Connectivity to this port is tested from the Oracle Identity Manager server.
The TCP/IP message transport layer relies on several different ports. The ports should be checked from the Oracle Identity Manager server to the mainframe. For provisioning to CA-ACF2, check for open ports between the two systems for port 5791. The Reconciliation Agent uses port 5190.

Note:

Check your specific setup configuration files for the actual provisioning and the Reconciliation Agent port numbers used in your deployment.
It is common for the mainframe TCP/IP configuration and the CA-ACF2 Advanced Connector Adapter JCLs to have the same code set, even if multiple LPARs and connectors are used. As the port traffic passes through a router, the public IP address then becomes different from the private locally assigned system IP address. This conversion of the private and public IP address can also extend to remapping to the ports.

Running Test Cases

This section focuses on the functional and performance test cases that are associated with this connector. The following table includes information on running test cases on the CA-ACF2 Advanced Connector:

Test Case	Test Type	Description/Comment
Test to Change CA-ACF2 Password	Provisioning	A user password is changed, with the change posted to the mainframe through the connector.
Test to Reset CA-ACF2 Password	Provisioning	A user password is reset, with the change posted to the mainframe through the connector.
Test to Create CA-ACF2 User	Provisioning	A user is created, with the change posted to the mainframe through the connector.
Test to Revoke/disable CA-ACF2 User Account	Provisioning	A user account is revoked, with the change posted to the mainframe through the connector.
Test to Resume CA-ACF2 User Account	Provisioning	A user account is resumed from a revoked status, with the change posted to the mainframe through the connector.
Test to List CA-ACF2 Users	Provisioning	A list of users is retrieved from the mainframe CA-ACF2 repository.
Test to Permit CA-ACF2 User Access to Resource Profile	Provisioning	A user is authorized to access mainframe resources, with change posted to the mainframe through the connector.
Test to Permit CA-ACF2 User Access to TSO	Provisioning	A user is provisioned to logon the mainframe through TSO, with the change posted to the mainframe through the connector.
Test to Remove CA-ACF2 User Access to Data set	Provisioning	A user is removed from access to a mainframe data set, with the change posted to the mainframe through the connector.
Test to Remove CA-ACF2 User Access to Resource Profile	Provisioning	A user is removed from access to a mainframe resource, with the change posted to the mainframe through the connector.
Test to Detect and Report Native CA-ACF2 Password Change Event	Reconciliation	A native password change is made on the mainframe and subsequently detected by the connector.
Test to Detect and Report Native CA-ACF2 Password Reset Event	Reconciliation	A native password reset is made on the mainframe and subsequently detected by the connector.
Test to Detect and Report Native CA-ACF2 Create User Data Event	Reconciliation	User creation is done by an administrator natively on the mainframe and subsequently detected by the connector.
Test to Detect and Report Native CA-ACF2 Revoke User Event	Reconciliation	A user account password is revoked through native mainframe events, which is subsequently detected by the connector.
Test to Detect and Report Native CA-ACF2 Delete User Event	Reconciliation	A user account is deleted through native mainframe events, which is subsequently detected by the connector.
Test to Detect and Report Native CA-ACF2 Resume User Event	Reconciliation	A user account is resumed from a revoke status through native mainframe events, which is subsequently detected by the connector.

Troubleshooting

The following table lists solutions to some commonly encountered issues associated with the CA-ACF2 Advanced Connector.

Problem Description	Solution
Oracle Identity Manager cannot establish a connection to the CA-ACF2 Server.	Ensure that the mainframe server is up and running. Check that the necessary ports are working. Due to the nature of the Provisioning Adapter, the Gateway must be started first, and then the mainframe JCL started task must be initiated. This is a requirement based on how TCP/IP operates. Check that the server IP which hosts the Gateway is configured in the Reconciliation Agent JCL. View the Gateway logs to determine if messages are being sent or received. Examine the Oracle Identity Manager configuration to verify that the IP address, admin ID, and admin password are correct. Check with the mainframe platform manager to verify that the mainframe user account and password have not been changed.
The mainframe does not appear to respond.	Ensure that the Oracle Identity Manager mappings are correct. Check the configuration mappings for the Advanced Adapter Gateway. Check that the mainframe JCL jobs have not ABENDED. If so, determine the reason for the ABEND and ask the mainframe administrator to restart the jobs.
A particular use case does not appear to be functioning.	Check for the use case event in question on the Gateway Server Log. Then check for the event in the specific log assigned to that Advanced Connector. If the event does not register in either of these two logs, investigate the connection between Oracle Identity Manager and the connector Gateway. If the event is in the log but the command has not had the intended change on a mainframe user profile, check for configuration and connections between the Gateway and the mainframe. Check that TCP/IP is turned on or that the IBM MQ series is operational, depending on the particular message transport layer chosen.

Performance Testing

The CA-ACF2 Advanced connector architecture has been engineered for enterprise-level performance. When an identity event passes through an exit, the Reconciliation Agent analyzes the event, and then creates a message, allowing the command to complete its routine without loss of time.

A given event will typically fire multiple exits at the same time. For example, a batch job that generates a password change identity event will fire both a batch exit and a password change exit. The Reconciliation Agent captures both events, filters duplicate entries, and passes the result to the Oracle Identity Manager LDAP Gateway.

A batch job to change 50,000 passwords has been tested on a single LPAR to complete within 10 minutes. Because two exits were involved, 100,000 messages were created, filtered, and transformed into MQ messages. The LDAP Gateway then took 30 minutes to retrieve and update the Oracle Identity Manager identity store, with most of that time consumed by the LDAP database.

The LDAP Gateway is engineered to detect when a given event originates from Oracle Identity Manager, when it passes through the Reconciliation Connector. The Provisioning Agent events also create a native exit event that is detected. To prevent a feedback loop, events that originate from the LDAP Gateway are logged, but are not reported again to Oracle Identity Manager. By contrast, events that originate outside Oracle Identity Manager are treated as native events, and recorded for future auditing.

The LDAP Gateway and Reconciliation securely capture, filter, and log the identity events from the host system, publishing them for use by Oracle Identity Manager.