Note: This document is not official product documentation from Oracle, for planning/executing any OIM upgrade activity, please follow the upgrade guide available here. If there are any doubts related to any of the steps/instructions mentioned below, please send your question to email@example.com.
1. Supported Source versions - 9101, 9102. More details here. WLS, JBoss, Oc4j customers, can upgrade to à WLS. WAS customers, no upgrade until R2PS1.
2. Pre-upgrade Analysis, what will get upgraded what not, Sizing changes etc.
a. Architectural analysis
i. Entity adapter (User), Connector – YES
ii. Security, Approval(Request), UI customization – NO
iii. Think of connector upgrade after OIM R2 upgrade.
iv. Plan for rebuilding the not-automatically-upgraded customizations after the upgrade (see Section B Step #14)
b. Data/Artifact level Analysis Pre-upgrade utility available on OTN (MOS: 1471905.1 - https://support.us.oracle.com/oip/faces/secure/km/DocumentDisplay.jspx?id=1471905.1&h=Y). Works on 91x DB and generates HTML output
E.g. Correct Application Instance creation, Flawless Access Policy upgrade, Pre-requisite DB packages to make catalog work.
3. Pre-upgrade checklist – take backups- database, OIM_HOME etc.
4. VERY IMPORTANT!! Explore the list of Known Issues carefully, as described in a separate section of this document below. A number of these have been fixed in additional patches on top of 11gR2 (hence Section B Step #13) and if not, be aware of the associated remediation step that needs to be carried out manually. Also before starting, keep a track of Troubleshooting tips provided in the product documentation - http://docs.oracle.com/cd/E27559_01/doc.1112/e28183/oim_up.htm#BABDGBIE
5. Download PS1 bits for WLS, SOA, IAM.
6. Schema creation – From the IAM PS1 RCU, run RCU to create OIM/SOA MDS and SOA schemas, not OIM schema. For Production, this step would be run against a RAC URL.
7. Software installation – From the downloaded bits, install WLS, SOA and IAM. It will create necessary home directories for Middleware, SOA and IAM/OIM.
8. Schema upgrade – From the IAM home, run Upgrade Assistant (UA) which would show options to upgrade schema and middleware of all IAM products (OIM, OAM etc.). Choose to upgrade database schema of OIM and it provide connectivity details of OIM 91x Db user. This would invoke UA MR (Metadata Repository) Plugin and upgrade the DB schema.
This step should run successfully on a HA DB (RAC) as long as the JDBC URL has been given properly.
9. Domain Creation and OIM config- Create a wls domain for OIM and SOA. Also start admin server and run OIM configuration wizard. If this is being done in production, then the domain has to be created as per the cluster-creation needs.
10. Middleware upgrade – Ensure Admin and SOA servers are running but not OIM. Run Upgrade Assistant (UA) which would show options to upgrade schema and middleware of all IAM products (OIM, OAM etc.). Choose to upgrade middleware of OIM and provide all details which are asked for. This would invoke UA MT (Middleware) Plugin and upgrade the MDS schema plus the domain which has been recently created. It carries out operations like CSF seeding, Request dataset creation, SOA composites generation (not deployment), Vacancy rule creation, Scheduled task creation from old ones in TSK, Recon profile generation and seeding and so forth.
11. Verification- Start OIM server. Run UA again and take the “Verify” option. It would try to open a static un-auth URL of OIM PS1.
12. Propagate to all nodes of the cluster – Take the domain from the upgraded environment machine1, pack it and unpack to all other nodes of the cluster.
1. Supported Source versions – 184.108.40.206/PS1. More details here. Not applicable for 91x but only PS1 customers
2. Pre-upgrade Analysis, what will get upgraded what not, Sizing changes etc. Not applicable for 91x but only PS1 customers. Run reports
3. Pre-upgrade checklist – take backups- database, middleware home, domain etc.
4. Download R2 bits for WLS, SOA, IAM.
5. Software upgrade – From the downloaded bits, upgrade WLS, SOA and IAM. It will update necessary home directories for Middleware, SOA and IAM/OIM. Installers themselves give option to “upgrade”.
6. Schema creation – From the IAM R2 RCU, run RCU to create OES/OPSS, its MDS and APM schemas. For Production, this step would be run against a RAC URL.
7. Extend the domain for DB based Policy store: It would carry out the OES/OPSS related upgrade steps which should setup the DB based policy store.
a. Datasources creation
8. Policy store re-association from PS1 file store to R2 DB store.
9. Schema upgrade – From the IAM home, run Patchset Assistant (PSA) which would show options to upgrade schema of all IAM products (OIM, OAM etc.). Choose to upgrade database schema of OIM and it provide connectivity details of OIM PS1 DB user and other schema like MDS, SOA etc. This step should run successfully on a HA DB (RAC) as long as the JDBC URL has been given properly.
10. Middleware upgrade – Ensure Admin and SOA servers are running but not OIM. Run Standalone OIM Upgrade script (OIM’s homegrown script) which would upgrade middleware and domain of OIM. Provide all details which are asked for. This would upgrade the MDS schema plus the domain configurations. This step logs on the execution to a HTML report.
a. SOA composites get deployed
b. Domain level configurations (New EARs deployed, old EARs redeployed)
c. OIM Data Migration to cover feature-level transformations
d. Feature Upgrade reports are generated.
11. Verification- Restart all servers (even this would carry out a lot of important steps for upgrade, like populating more policies to DB policy store etc.). This step also logs on the execution to a HTML report. Navigate to the relevant directory and check all reports for verification of upgrade and errors if any, to plan manual remediation. Remediation example is to merge MDS documents manually.
12. Post-upgrade steps:
a. Ensure to manually address if there is any minor impact on the connectors, as captured in this wiki. (Appendix A)
b. Run catalog synch etc.
c. Follow more steps as defined in product documentation.
d. Test basic Access Request and Provisioning scenarios. If any such basic use case fails, do not proceed further. Move ahead with the standard procedure you would follow when a blocker issue is observed in any development cycle.
13. Additional Patching : Apply R2BP01 and all the latest one-off patches available after that (e.g. 14287866), some upgrade issues have been fixed there. If BP0n (n>1) is available, only apply that instead as it would include cumulative fix for all the issues identified till date.
14. Manual development of customization: UI customizations, Security, Pre-population of request forms
15. Propagate to all nodes of the cluster – Take the domain from the upgraded environment machine1, pack it and unpack to all other nodes of the cluster. The domain footprint will already be present on all the nodes as it was an existing PS1 environment but will get updated as part of unpack.
1. Application inst à Get created automatically thru upgrade. But security etc will not be configured, i.e. these app instances would have to be explicitly published to required organizations as per customer requirements and unpublished from top (where they get published by default)
2. The relevant Child form attributes need to be tagged as entitlement, by defining a property “Entitlement=true”.
3. “ITResource=true” needs to be added as a property for the relevant IT resource field on the process form, if there are more than one IT Resources on the form. E.g. in case the connector is using Remote Manager.
4. “Account Name” and “Account ID” properties need to be set as “true” for relevant attributes.
5. If there are more than one lookup fields in a child form the entitlement request will not work.
6. R2 supports account password reset as the first class operation. User can reset password for any target from the self service. R2 make assumption that the password fields in the process form follows the ‘<FORMNAME>_PASSWORD’. This might not be true for all connectors. If the connector is not following this form the password reset operation is not available from self.
7. For implementing Pre-population of application instance form rendered on Catalog page, UI customization needs to be done using managed beans. Please follow the dev guide. A relevant asset will soon be uploaded to OTN OIM 11g assets page.
8. For implementing Dependent lookups (or cascading LOVs) in application instance form rendered on Catalog page, UI customization needs to be done using managed beans. Please follow the dev guide. A relevant asset will soon be uploaded to OTN OIM 11g assets page.
9. The way to model internationalization for account and entitlement attributes managed by a connector/application instance, has changed. The updated
1. Issue - ICF based connectors might stop working after upgrade.
Remediation – Manually add the following entry in the oim-config.xml file:
2. Issue – API clients working with PS1 installation will not work anymore with R2.
Remediation – Add the following OS-level env variable on the machine where client applicatio9n is running from
In the classpath, add the following jar
And also repackage the client application including the other latest jars from OIM R2 server.
3. Issue – SOA emails sent to approvers for taking action didn't have request details, instead showed javax.security.auth.login.FailedLoginException
Remediation – Do follow the step mentioned in this document link.
4. Issue – After completing the upgrade when OIM server is started, it might come up in ADMIN status. The UI related ears might not get deployed.
Remediation – Target "oracle.soa.worklist.webapp" to oim cluster server (along with SOA cluster) which was missing earlier.
5. Issue - Deployment mode in OIM config might be incorrect after upgrade, in the production environment. It gets set as “simple” instead of “Cluster” in oim-config.xml
Remediation – Change the deployment mode to cluster, instead of simple. This can be done by exporting the file from MDS, editing and importing back or by using EM for editing the OIM config xml entry.
6. Issue - access the identity / sysadmin url’s now the login screen is displayed but after providing the credentials the next page is not displayed and an exception is shown.
Remediation - There would be a custom event handler code using Transaction Manager explicitly, and there is a problem in the way it might be getting initialized. The Transaction Manager has changed in R2, getPlatformTransactionManager() method is removed, so the event handler would not get initialized and could cause issues. The relevant custom event handler, need to be changed and redeployed. For getting complete details on the relevant change, please contact Oracle support for now. The instructions will also be available in Oracle product documentation soon. It is about removing the txn management calls from the event handler code and instead marking the “txn” attribute as “true” in the event handler configuration xml file.
7. Issue - When trying to add items to cart / creating a new role from UI, you might get ADF JBO exception.
Remediation –/tmp/wls_user directory should be cleaned up to resolve this issue.
8. Issue – There could be some UDFs on OIM User schema which had the display type configured as “Lookup”. Their display type will get converted to a “Text” mode after upgrade.
Remediation –Follow the manual steps mentioned in defect 15879277.
9. Issue – GTC based connectors can give some issues while editing their metadata, after upgrade
Remediation – Please check if the underlying Application instance for this GTC has got created successfully. If not, please create a sandbox and create this application instance manually. The name of the Applications instance should be exactly same as the name of the GTC connector itself.
More Middleware Downloads