Skip to Main Content

E-Business Suite

Announcement

For appeals, questions and feedback about Oracle Forums, please email oracle-forums-moderators_us@oracle.com. Technical questions should be asked in the appropriate category. Thank you!

Interested in getting your voice heard by members of the Developer Marketing team at Oracle? Check out this post for AppDev or this post for AI focus group information.

CRUD employee records, users and their access rights / roles through REST API

Hi,

We're having some difficulty finding in depth documentation on the Oracle EBS REST API's and whether or not to use Integrated SOA Gateway (ISG).

Our goals:

  1. Creating, reading, updating, deleting employee records in Oracle EBS’s HR module
  2. Creating, reading, updating, deleting Oracle EBS user accounts for some of these employees
  3. Assigning / removing Oracle EBS systemroles for these user accounts, giving them access to certain functionality/data

From documentation we've understood that we need to expose the relevant Oracle EBS PL/SQL API's through Integrated SOA Gateway (ISG) first, but our pre-sales contact at Oracle later told that using ISG wasn't required. This leaves us a bit confused. In depth documentation we also haven't found yet.

Our questions:

  1. Do we need ISG to expose the relevant Oracle EBS PL/SQL API's as REST services?
  2. If so, which of Oracle EBS’s PL/SQL API’s need to be exposed as REST API’s exactly, to achieve our goals (mentioned above)?
  3. What are the exact interface specifications for these, once exposed as REST API’s?
    1. Relative URL for resources involved
    2. HTTP operations
    3. Request parameters
    4. Request and response bodies

Unfortunately, we don't have access to the customer environment yet. We don't want to wait for that and rather have a head start by studying and prototyping connectivity with the API's involved.

Any help in achieving our goals is greatly appreciated.

Thanks.

Comments

thatJeffSmith-Oracle Feb 13 2025

Your ENTRA users will get authenticated via JSON Web Tokens, and their Entra roles will determine which ORDS REST APIs they can hit.

When they hit an endpoint, it'll execute code in the database as the database user that owns the schema where the REST API is defined, not as Entra defiend end user. In fact, the Entra users won't have accounts in the database (they could, but wont' need to).

The :current_user field as far as ords is concerned would be the corresponding oauth2 client or JWT issued for the authorizied session.

Your prehook should be able to alter the session to set the context that would put your RLS/VPD security policy in play.

1 - 1

Post Details

Added on Dec 9 2024
2 comments
353 views