Fault handling in OIC by Jan Kettenis

This article discusses how fault handling in Integrations works for the Oracle Integration Cloud, and some best practices on how to use it, including consuming Integrations in Structured Processes.

Updated on August 6 2020 after discovering that in the explanation of Fault Return parts of the text were duplicated while others were missing.

Special thanks to Greg Mally of the Oracle A-Team for his valuable input.

As this is a lengthy article I will start with the conclusion including what I consider to be the best practices, so if you trust me you can stop right there

Best practice is to always put an Invoke activity in a Scope. In case you need to handle a fault in a specific way, it is sufficient to add a Default (Fault) Handler only, unless you need to handle different back-end faults differently.

In the Fault Handler use the Fault Return option to throw a fault coming from the back-end service to the consumer of the Integration for three reasons:

1. It gives you maximum control over the way the fault is returned to the consumer. For example, only with Fault Return will you be able to return the HTTP 4xx or 5xx status code from the back-end service as-is to the consumer of a REST Integration.
2. With that it allows you to wrap the fault from the back-end services in one single type of fault thrown to the consumer, making fault handling by the consumer as simple as possible. For example, in case of a modeled SOAP Fault returned to a Structured Process, it now suffices to add one single Boundary Error Event for the modeled fault to handle all business faults in the process.
3. On the Monitoring tab the integration instance that handled the fault from the back-end service is itself flagged as “Succeeded” (instead of “Errored”), which strictly speaking is correct as the integration did what it had to do (don’t blame the messenger). After all, the actual fault happened in the back-end service. So instead of unnecessarily alarming the operator of OIC (which caused no issue), Operations should look at either the consumer or the back-end service to find out what went wrong.

In other words, Fault Return is the easiest way to return faults thrown by the back-end service(s) in a consistent way. This is can be very convenient for your consumer. Read the complete article here.

PaaS Partner Community

For regular information on Oracle PaaS become a member in the PaaS (Integration & Process) Partner Community please register here.

Blog Twitter LinkedIn Facebook Wiki

Technorati Tags: SOA Community,Oracle SOA,Oracle BPM,OPN,Jürgen Kress

OIC: Integration Pick action full-circle now with Process using it! By Jan Kettenis

This article describes how the Pick feature aka Multi-Operation Support for REST integrations now also is fully supported by Process applications.
More than a year ago the Pick action was introduced in OIC also known as Multi-Operation Support. Since then you can create REST integrations supporting multiple actions for one resource using one single URL. For example, you can have one single endpoint like …/ic/api/integration/v1/flows/rest/INT_GN_CASE_GROUPS/2.0/case-metadata/casegroups supporting a POST, GET, PUT and DELETE.

Apart from the fact that it is the de-facto standard for developing REST services to handle one single resource, it also is more convenient to have one single Integration that you can activate or deactivate instead of creating as many integrations as there are actions. Until the August 2020 release it was not yet supported by Process, but finally it is!! Now why would you want this? In short: because is easier and it performs better. Read the complete article here.

PaaS Partner Community

For regular information on Oracle PaaS become a member in the PaaS (Integration & Process) Partner Community please register here.

Blog Twitter LinkedIn Facebook Wiki

Technorati Tags: SOA Community,Oracle SOA,Oracle BPM,OPN,Jürgen Kress

Oracle Process Cloud – linking to a process instance by Niall Commiskey

Use case here – Customer wants a process creator to be notified when a process has completed. In this case, an email containing a link to the process history in Workspace. The link should bring me here – The link has the following format. I try this out with the my instance id – Now to my process – not the most complex of processes, I’m sure you will agree. Read the complete article here.

PaaS Partner Community

For regular information on Oracle PaaS become a member in the PaaS (Integration & Process) Partner Community please register here.

Blog Twitter LinkedIn Facebook Wiki

Technorati Tags: SOA Community,Oracle SOA,Oracle BPM,OPN,Jürgen Kress

Understand Decision Model Views

In Processes, you can work on a decision model using either the graph view or the list view. When you create a new decision model, you’re presented with the graph view by default. You can switch to the list view and vice versa using the Menu button in the toolbar.

Note: The decision models that you’ve created previously will continue to use the list view as the default view. If you switch to the graph view, you’ll need to redefine the relationships between decisions and input data elements. Similarly, you’ll have to redefine the order of the decisions if you switch from the graph view to the list view.

Topics:

· Graph View

· List View

Graph View

In the graph view, you can create decision requirement diagrams (DRD), in accordance with the DMN standard, to visually represent your decision models.

In decision modeling, a decision requirement graph (DRG) is a self-contained representation of an entire domain of decision-making that displays the important elements in the domain and the relationships between the elements. Whereas, a decision requirement diagram typically depicts a specific view of a DRG; the view depicted can either be partial or complete.

Processes currently supports one DRD per decision model. The following table lists all the available DRD components, which you can use to create your decision models.  Read the complete article here.

PaaS Partner Community

For regular information on Oracle PaaS become a member in the PaaS (Integration & Process) Partner Community please register here.

Blog Twitter LinkedIn Facebook Wiki

Technorati Tags: SOA Community,Oracle SOA,Oracle BPM,OPN,Jürgen Kress

Use Oracle Integration to Add Attachments to a Process Instance

Use Oracle Integration to Add Attachments to a Process Instance by Bogdan Eremia

The other day it came to my attention that it’s not really straightforward to add attachments to an Oracle Process Instance using the REST API.

One reason for this is that it requires multipart/mixed media type for the request body message format, and producing this kind format is not so common for JavaScript clients. The JS clients are more used to working with multipart/form-data, the de-facto standard for form-based file upload in HTML.

One way of overcoming this is to use Oracle Integration Cloud (OIC) between the JS client and Process REST API. OIC has a REST Technology Adapter that supports sending/receiving attachments in both multipart/mixed and multipart/form-data media types. The goal is to shape in OIC a REST interface that accepts multipart/form-data, to do a translation into multipart/mixed (alongside with other transformations/actions if required) and to call the Process REST API. Below are the main steps for achieving this.

1. Create a REST Connection in OIC for Process REST API.

Go to OIC Homepage > Designer > Connections to create a new connection by selecting the REST Adapter. Read the complete article here.

PaaS Partner Community

For regular information on Oracle PaaS become a member in the PaaS (Integration & Process) Partner Community please register here.

Blog Twitter LinkedIn Facebook Wiki

Technorati Tags: SOA Community,Oracle SOA,Oracle BPM,OPN,Jürgen Kress

OIC: Identity Propagation In Structured Process by Jan Kettenis

When a process calls a service you sometimes have a requirement that some user identity needs to be propagated to the service call. This article describes how you can propagate the identity (but alas not the principle) of a user on behalf of whom a service call is executed. When calling a service in a structured process you sometimes must pass on the identity of the user that called the service. This could be the case when that service call is done to a SaaS application and it is required to track on behalf of whom that service is called. The identity (user name) only is not enough when authentication must happen using the principle (security token) of the user, but there are applications that can handle this using some combination of a system user (or client id plus secret) with an on behalf of user. And there are situations where having an on behalf of user only is enough, like when storing data in a database table with audit columns (you don’t want all the end users also to be database users so passing on the user’s principle to the DB would not make sense).
It is not always trivial who that on behalf of user should be. Take for example the following process model: Read the complete article here.

PaaS Partner Community

For regular information on Oracle PaaS become a member in the PaaS (Integration & Process) Partner Community please register here.

Blog Twitter LinkedIn Facebook Wiki

Technorati Tags: SOA Community,Oracle SOA,Oracle BPM,OPN,Jürgen Kress