1. Implementing Risk Management
  2. Set Up EPM Data Sources

Set Up EPM Data Sources

If you want Risk Management to evaluate data from EPM Account Reconciliation, you must set up an EPM-ARCS data source. If you want Risk Management to evaluate data from up to three Financial Consolidation and Close pods, you need to set up a distinct EPM-FCCS data source for each of them. Setup involves establishing a connection to an EPM server and running synchronization jobs that refresh EPM data in Risk Management.

One step in connecting to an EPM server is to provide authentication details, and those details depend on which of two authentication protocols you use. Each applies to an EPM instance deployed as a cloud service in Oracle Cloud Infrastructure (OCI); on-premises deployments aren't supported.

  • An Open Authorization 2.0 (OAuth2) protocol is recommended for production, but you can use it only if your EPM deployment integrates EPM with Oracle Identity Cloud Service (IDCS).

  • A basic authorization protocol is required for a "classic" EPM deployment (one without IDCS integration). Even if your EPM deployment qualifies for the OAuth2 protocol, you may use the basic protocol instead.

In either case, you'll use a setup page to provide authentication details for the data source. Before you begin the setup procedure, you should determine what these values are. You may need to consult with your EPM system administrator.

If you use the basic protocol, authentication details include the following four values:

  • API Credentials > User Name: The name for a user account in the data source you're setting up, either EPM-ARCS or an EPM-FCCS pod. This user must have the Service Administrator role. Risk Management uses this account to connect to EPM to fetch data for analysis.

  • API Credentials > Secret Key: The password paired to the User Name. This password may be subject to expiration. If so, update it when it expires, then rerun the setup procedure, entering the new password value as you do.

  • Authorization > Protocol Type: The correct protocol type is Basic authentication.

  • Authorization > Host: The https URL of the server for the data source you're setting up, either EPM-ARCS or an EPM-FCCS pod.

If you use the OAuth2 protocol, provide the following values.

  • API Credentials > API Key: The client ID for the REST client application registered in the IDCS system.

  • Authorization > Protocol Type: The correct protocol type is Open authorization 2.0. It's the default value.

  • Authorization > Authorization Scope: The authorization scope for the EPM instance.

  • Authorization > Host: The https URL of the server for the data source you're setting up, either EPM-ARCS or an EPM-FCCS pod.

  • Authorization > Token URL: The token URL for the IDCS instance paired with the EPM-ARCS instance or EPM-FCCS pod you're setting up. For IDCS this value is the base URL, with the following value added: /oauth2/v1/token

  • Authorization > Grant Type: The correct grant type is JWTAssertion. It's the default value.

  • Ignore any other fields in the API Credentials and Authorization sections of the setup page.

If you use the OAuth2 protocol, you must also use an Assertion section of the setup page to specify two values, a Client Assertion and a User Assertion. You can, but typically shouldn't, supply these assertion values directly. Instead, you can supply values in the following five fields, from which the application generates the assertions.

  • Assertion > User Name: The name for a user account in the data source you're setting up, either EPM-ARCS or an EPM-FCCS pod. This user must have the Service Administrator role. Risk Management uses this account to connect to EPM to fetch data for analysis.

  • Assertion > Key Alias: The alias for the public certificate imported into IDCS.

  • Assertion > Audience List: The audience list value for generating OAuth2 assertions. For IDCS this value is https://identity.oraclecloud.com/

  • Assertion > Public Certificate: The public certificate value imported into IDCS for validating OAuth2 assertions.

  • Assertion > Private Key: The private key value for generating OAuth2 assertions.

More about these assertions:

  • The application saves the two assertion values, but not the other values, in the Fusion credential store. The assertion values eventually expire. By default, they remain in force for one year. To create new assertions, you would rerun the setup procedure, and would reenter all of the required values to do so. The application doesn't save them because they're considered to be sensitive data.

  • You would supply the assertion values directly, in Client Assertion and User Assertion fields, only if you want to change the default behavior of the assertions, for example by designating a shorter time until expiration. But you would have to create them. You can use a tool called OpenSSL to do so. However, this would require you to have an in-depth understanding of OpenSSL and assertions.

  • If you supply the two assertions, leave the other five fields blank. If you supply values in the other five fields, leave the two assertion fields blank.

Complete these steps to set up an EPM-ARCS or EPM-FCCS data source:

  1. Navigate to Risk Management > Setup and Administration > Advanced Controls Configuration.

  2. In the Non-Fusion Data Sources panel, locate the row for the EPM-ARCS data source, or one of three rows (numbered 1 through 3) for EPM-FCCS pods. Initially, each of these rows displays a Not set up sync status. Click the Edit Credentials icon.

  3. An Enter Authentication Details page opens. In it, the Authorization > Protocol Type field defaults to the value Open authorization 2.0. Accept that value if you use the OAuth2 protocol; if not, select Basic authentication. Depending on your selection in the Protocol Type field, the page presents fields appropriate for your protocol. In either case, enter the authentication details you've determined are correct for the data source you're setting up.

  4. Click the Test Connection button. When a message confirms that your authentication details are valid, click the Update button.

  5. The focus returns to the Advanced Controls Configuration page. In the row for the data source you're setting up, there are now two sync-status fields, one for access analysis and the other for transaction analysis. The value of each is Not started.

    In that row, expand the Actions menu. In it, select the Run Access Sync option to prepare for access analysis, or the Run Transaction Sync option to prepare for transaction analysis.

  6. A message displays a job number. Make a note of the number and close the message. Click the Go back icon and, in the Monitor Jobs page, locate the row for your job number to track the progress of the job.

  7. When the job has finished running, click the Advanced Controls Configuration tab. In the row for the data source you're setting up, the sync-status value for the job you ran is now Completed.

  8. You can stop at this point. If you intend to perform both access and transaction analysis, however, you need to run the second synchronization job. To do so, repeat steps 5 to 7, but select the Actions menu option for the job you haven’t yet run.

Two fields in the data-source row show the most recent dates on which access synchronization succeeded and was attempted. Two more fields provide the same information for transaction synchronization. (For each synch job, the successful and attempted dates are initially the same, but they may differ if a later job run results in errors.)

Note: For optimal performance, transaction-data synchronization operates on EPM records created or updated on or after a cutoff date. It’s the same as the cutoff date for transaction synchronization in the Oracle Cloud data source, which is set in the Transaction and Audit Performance Configuration panel of the Advanced Controls Configuration page.