Connectors at a Glance

Start by familiarizing yourself with these connector concepts.

How are connectors used in process applications?

Use an outbound connector to call a REST service to retrieve, create, update, or delete data on a web server that supports the REST architecture. The connector enables process applications to interact with other Oracle Cloud applications via REST including SaaS and PaaS applications running inside or outside Oracle Cloud.

You can create and use two kinds of connectors in Process Automation - REST connectors and Integration connectors. Use REST connectors to connect to external services and applications. Use integration connectors to connect to active integrations in Oracle Integration that are designed with REST triggers.

Once configured, connectors can be implemented in:

• Service activities in structured or dynamic processes

• Integration activities in structured processes

• Forms when a field needs values from a REST call

How are REST connectors configured?

Using the REST Connector editor, you define the resources and operations needed to connect to a REST service, regardless of the description language used to define the service. Configuring a connector involves defining its:

• base (or target) URL

• resources

• operations

• security

What service information do I need to know?

You’ll need the following:

• URLs to the location of resources to call

• Access to resources to get a JSON sample or schema to create the types needed to send and receive data to and from the service

• List of operations to use on each resource

• List of parameters to pass to operations

How can I secure REST connector calls?

You can secure REST connector calls in one of several ways, depending on the resources you’re calling and your organization’s needs.

Security Type	Description	Supported Grant Type
No Security	REST calls are not secured.	Not applicable
Basic Auth	Provides basic username/password authentication credentials with each request.	Not applicable
OAuth 2.0	Uses OAuth security tokens for making outbound calls to external services. If you choose OAuth 2.0 security, you’ll need to follow steps to generate and gather Oracle Identity Cloud Service-related information needed.	JWT Assertion Client Credential
OCI Signature Policy	Provides a secure way for an OCI Service such as Oracle Cloud Infrastructure Process Automation to interact with service consumers.	Not applicable

Which OAuth grant type credential should I create?

Your process needs determine the OAuth grant type to choose: JWT Assertion or Client Credential.

• Use Client Credential when invoking a system that requires secured communication but doesn’t require a user identity to be present in it. The client credential identifies the OAuth client and not the user.

  Example: You may want to invoke Oracle Identity Cloud Service or Oracle Integration APIs using client credential security, since they typically don’t require a user identity.

• Use JWT Assertion for system-to-system communication that requires invoking on behalf of a specific user without taking consent from that user.

  Example 1: Model a Process-to-customer system process (structured or dynamic) that invokes endpoints on behalf of the user who creates the process. Use a service task connector that makes a call on behalf of the initiating user, creating an OAuth token using that user and JWT Assertion, and invoke the target endpoint.

  Example 2: The Process Automation forms connector also supports invoking endpoints on behalf of the user. Suppose you configure a form with a connector that fetches information from an HCM system. If the connector is configured to use a JWT assertion credential, it automatically uses the user identity of the current logged in user accessing the form to generate an OAuth token to make a call to the HCM system and get information.

How do global credentials work?

Process Automation Administrators can create global credentials (Basic, OAuth, OCI Signature Policy) in Workspace. In Designer, Process Automation Designers can find and apply a global credential to a selected connector.

Note that any changes an administrator makes to a global credential, are applied in all connectors in all process applications (activated or not) in which the global credential is used.

How are credentials stored?

Credentials are stored centrally. They are separate from a process application’s metadata and aren’t exported or imported with a process application. Process AutomationAdministrators can share credentials by creating global ones that Process Automation Designers can select for a process application.