OIC - Oracle Feature Flag overview

Colleced from Oracle #enabling-the-future-today-feature-flags-in-oracle-integration

Feature Flag Overview

Within Oracle Integration we are moving to a model that allows us to trial new features without making them available to everyone.  Everyone runs the same codebase but feature flags control what is available to a specific instance.

How It Works

Each new feature is given a flag that is used to control its availability.  For instance the flag for the small footprint OIC agent was oic.adapters.connectivity-agent.light-weight-agent.  If this flag was enabled for a given OIC instance then they could download the lightweight connectivity agent.  Other OIC instances running the same code but with the flag turned off would not offer the new agent.

Flags are controlled from a central system and can be updated in real time by Oracle development and operations.  This means that feature flags can be turned on very quickly, and also if a problem occurs they can be disabled.

Feature Flag Lifecycle

Feature flags have a lifecycle as illustrated below.

The different stages are:

Internal Only

You may see a product manager demo features on an instance that are not currently available, if using a production pod these may only be available to internal users.  This is where we try things out internally before turning them on for any customers.  Once we are happy with the feature internally we are ready to share it with selected customers and move the feature to Feature Controlled.  Note that this change in stage does not require any code changes, it just alters our internal approval process to enable the feature.

Feature Controlled

Once a feature enters the feature controlled stage then a customer may request that the flag be enabled for one or more of their OIC instances.  If approved then those instances will have the flag enabled and the feature will become available within a few minutes of being enabled.  Again there are no code changes to the customer instance, just the change in the flag status from disabled to enabled in the central feature flag server.

Feature Controlled General Availability

Once we are happy with the stability of a feature we will enable it for all instances.  This again does not require a code change.  We leave the flag in place so that if a specific customer has a problem we can disable the feature just for them or roll it back.  This is a safety measure in case problems occur that were not caught by internal users or early adopters of the feature.

General Availability

Eventually the flag controlling the feature will be removed.  This has no impact on the end user, it just allows us to keep the code paths clean and remove unused code that has been made obsolete by the new feature.  End user will see no difference between this stage and the previous one.  So I mention it here only to explain how we keep our codebase clean.

How to check features from OIC console:

Login your OIC instance and go to profile and then to about section. You can see the Enabled Features.

In my OIC instance, currently no feature is enabled. So its showing empty.

OIC - How to schedule an integration using iCal expression

Use case:

Here, we will shedule an integration for every 5 minutes interval of time using iCal exp.

Implementation steps:

Step1: choose the scheduled integration and click on actions and select Add schedule.

Step2: select iCal option and privide the below iCal expression to schedule for every 5 mintues interval of time.

FREQ=MINUTELY;INTERVAL=5;

Click validate epression and save

Step3: start the shedule

Step4: now it will show all the future runs for every 5 mintues interval.

Few of the complex iCal exp:

Shedule every 3 years on May 2nd and 7th:

FREQ=YEARLY;INTERVAL=3;BYMONTH=5;BYDAY=2,7;

Schedule each month on the 1st,5th and 10th days of the month at 5:30AM, 10:30AM , 3:30PM

FREQ=MONTHLY;BYMONTHDAY=1,5,10;BYHOUR=5,10,15;BYMINUTE=30

We can also define multiple schedule frequencies using & sign.

Schedule every day 8 am and 8 pm

FREQ=DAILY;BYHOUR=08;BYMINUTE=00;BYSECOND=0;&

FREQ=DAILY;BYHOUR=20;BYMINUTE=00;BYSECOND=0;

OIC - How to modify an existing schedule | Update schedule | Oracle Integration Cloud

We have following 2 methods to modify an schedule:

Method 1: Pause and stop the schedule and update the schedule.

Integration page or monitoring Integration page >> Actions >>Schedule >> pause >> stop >> Edit >> save >> Start schedule

Method2:

• Delete the existing schedule
• Add the schedule

Step1: Click on the hamburger sign or actions and click on schedule

Step2: click on Menu and click delete schedule

Step3:  click on add schedule

Step4: Then define your shedule whether to choose simple type or iCal and save.

Step5: start the schedule.

OIC - How to schedule OIC integration using simple type

Using simple type of scheduling, we can schedule the integrations in the following frequencies:

• Only once
• Hours and Minutes
• Days
• Weeks
• Months
• Day of every week & week of every month
• Day of every month
• Months of every year

Note: if you need advanced setting or less than 10 minutes interval, then you have to use iCal.

Use Case: 

We will create a dummy schedule orchestrated integration and schedule the integration for every 10 minutes using simple type of reocurrence. 

Note: We can not define an integration below of 10 minutes using simple type. If you try to do, it will throw below error(see the screenshot). Use iCal to schedule the integration below 10 minutes.

Step1: activate the scheduled integration and then click on the hamburger sign and select Add schedule.

Step2:  click frequency as Hours and Minutes as we will configure 10 minutes.

Step3:  define 10 minutes and save.

Step4: Now click on start schedule.

Step5 : now It will show all the runs which are yet to start and waiting state.

Bash Shell script - all in one place

 

Bash scripting - part1 - introduction variable loops decision making statements comments

Bash scripting - part2 - positional params STDIN sourcing a config return code exit functions

Bash scripting part3 - variable scope let case eval wildcards logger reading a file line by line expr loop control statements debugging

Bash scripting - part4- SED awk

OIC - Fault return - send custom fault to modeled soap trigger

Here, I will describe how we can send custom faults to a modeled soap trigger.

Use case:

We will create a soap trigger connection based on a request response and modeled fault wsdl and from the integration, will call an external rest service and the twist is, we will provide invalid rest url and keep all this activities in a scope and from scope APIInvocationError we will customize the fault to the modeled soap to consumer.

Implementation steps:.

Step1: First we should have a request-response with modeled fault wsdl. Then create a soap trigger connection using the wsdl.

Fault schema contains errorCode,error and error details fields.

Step2: create a rest invoke connection using external or internal OIC rest service URL. 

Here, I used the following url:.

https://jsonplaceholder.typicode.com/users/1.

Step3: create an app driven integration and configure the soap trigger using the created soap trigger connection.

Step4: create a scope and drag and drop created rest invoke connection and configure it with all details

Endpoint name,

Uri: /1users/{User-id} // purposefully provided wrong uri.

Verb: get

In response section, provide the rest Json response payload

Next map the id and map the response to the soap trigger.

Now the integration flow looks as

Step5: click on the fault handler and choose APIInvocation error. Drag and drop Fault return action and map the $CurrentFaultObject details to soap modeled fault.

Note: you can also define default fault handler.

Step6: save, add tracking id and activate and test with input. You will see your modeled error as below screenshot:

OIC - Fault Return action - Custom HTTP Error response in rest flows

Why Fault return:

The REST adapter allows to expose the HTTP endpoint that HTTP clients can request and returns an HTTP response. On successful call, it gets a HTTP status code with the response. On error, it returns an error response with an HTTP status  belonging to the HTTP error family of codes depending on the fault situation.

Using this Fault return action, we can send custom error response to the consumer. For example,

We can send 400 Bad request, if some manadatory params are missing.

Use case:

We will create an app driven service and use rest service trigger with input query field "id" and response "name". We will create a logic, if id is not empty then harcode a name to the response otherwise we will take a fault return action and send a custom error message to the consumer.

Steps of implementation:

Step1: Create an appdriven integration and drag and drop rest trigger connection and configure :

Endpoint name

URI: /custom

Verb: get

Add and review params for this endpoint

Configure this endpoint to receive the response

Next

Add Query parameter 

Name: id and data type : string

In response section, choose JSON and inline and write as below

{

"Name":"samplename"

}

Next

Done.

Now the integration flow look like:

Step2: add a switch action and add the following condition

Id !=""

And hardcode a name to the response.

Step3: in the otherwise block,  add fault return activity and map the error code, type error details as customized as per your requirement.

Here, I have customize erros as below:

Error code: '400'

Type: '400, Bad Request'

Title: 'id field value is empty or missing'

Now the Integration flow looks as below

Step4: add tracking as id, save, activate and run test with empty id. You will see your customized error: