Showing posts with label OIC. Show all posts
Showing posts with label OIC. Show all posts

Tuesday, July 20, 2021

OIC - get ESS JOB Status of a ESS import job

Here, I will show you how to get the ESS job status once the import job completed and you have the ess import request id.

Logic: 

we will create a loop and check the ess job status using the import request id whether the ess import job is successful or not(at each loop it will wait 59 sec). 




Follow the below steps:

Step1: Take an assign activity named like setImportLoopVariable and assign the following 2 variables:

I_inProgress : "true"

I_importRequestStatus : ""

Step2: take a while activity and add the following condition.

$I_inProgress = "true"

Step3: Take a wait activity and assign some time to complete the import ESS process lika value 59sec.

Step4: Drag and drop Erp cloud adapter and configure following:

Provide a name: essJobStatus

Select Query, Create, Update or delete information.

Select service: ErpIntegrationService

Operation: getESSJobStatus

Step5: Map the ess import request id to request id of the getEssJobstatus.

Step6: Take a assign named like updateProgress and do the following:

I_inProgress : returnStatus(result of getESSJobStatusResponse)

I_importRequestStatus: result of getESSJobStatusResponse.


Click here how to convert the status to boolean value:

oic-js-return-boolean-status


Saturday, July 17, 2021

OIC - Convert a Scheduled Integration to a REST Adapter-Triggered Orchestration Integration

You can convert a scheduled integration to a REST Adapter-triggered, app driven orchestration integration. This eliminates the need to recreate the integration if you need to change the integration style from scheduled to app driven orchestration.

Restrictions:

  • You cannot convert a scheduled integration to a REST Adapter-triggered integration with multiple verbs.
  • You cannot convert a scheduled integration with assignments that have the fault data type.

Implementation steps:

Step1: In the left navigation pane, click Home > Integrations > Integrations > de activate and Open the scheduled integration you want to convert.

The integration canvas is displayed.

Right-click the schedule icon and select Convert to REST Trigger.



Menu is displayed with selections for Edit Schedule Definition, Edit Integration Properties, View Integration Properties, and Convert to REST Trigger.


Step2: A list of available REST Adapter triggers is displayed > Select the REST Adapter to use as the trigger connection in this integration. > This invokes the Adapter Endpoint Configuration Wizard. Configure the REST Adapter in the wizard.

When wizard configuration is complete, click Done.

A message is displayed.

Clicking done will perform conversion to REST trigger and will clear tracking information, delete any assignment variables with fault data types and update any impacted actions. Errors and warnings may occur which will require manual correction. Are you sure you want to continue?

Review the message, then click Convert.

Step3: A conversion progress bar is displayed. When complete, the converted integration is displayed in the canvas with the REST Adapter trigger connection.

The integration is displayed horizontally. Conversion errors identified by little red circles are displayed on the impacted actions in the integration.

Step4: Investigate any errors and manually correct the impacted actions or invokes. For example, any scheduled parameters in the scheduled integration are deleted during conversion to an app driven orchestrated integration. This results in errors in any actions that reference those schedule parameters (for example, an assign or logger action).

OIC - Why to avoid creating too many scheduled integrations

When there are too many scheduled integrations configured, instances can get backlogged waiting for resources to become available or previous integration runs to complete. This can cause processing delays where some instances are in a waiting state longer than they should be and schedules may not start at the scheduled time.

Best practice:

  • Do not create too many scheduled integrations that are scheduled to run at the same time. 
  • Use an asynchronous REST Adapter trigger instead of a scheduled trigger when an active schedule is not absolutely required.
  • Do not create any long-running scheduled integrations (a scheduled integration that takes longer than one hour, for example, to complete). This blocks scheduler resources impacting other scheduled runs.
  • Spread schedules out over time to avoid schedule clusters.
  • You can convert a scheduled integration to an application-driven orchestrated, REST Adapter trigger-based integration. 

Sunday, July 11, 2021

OIC - Common Integration Pattern Pitfalls and Design Best Practices

Common Integration Pattern Pitfalls and Design Best Practices:

Note the following best practices and integration pattern pitfalls to avoid when designing an integration.

  • Avoid Common Integration Pattern Pitfalls
  • Avoid Creating Too Many Scheduled Integrations
  • Synchronous Integration Best Practices
  • Design Long-Running or Time-Consuming Integrations as Asynchronous Flows
  • Time Outs in Service Calls During Synchronous Invocations
  • Parallel Processing in Outbound Integrations

Avoid Common Integration Pattern Pitfalls

  • Chatty Integrations
  • Scheduled Job that Never Stops Trying to Process
  • lmport an Externally Updated IAR File
  • Synchronous Integration Doing Too Much
  • Too Many Connections in an Integration
  • Read Files with Many Records'
  • Integrations Running Unchanged Despite Changing Business Needs

1. Chatty Integrations:

Use case: 
Synchronise records in a file or large data set with an external system.

Pitfall:
Use an invoke activity within a looping constuct to call external APIs for every record.

Why pitfall:
Downstream apps are receiving a large number of atomic requests. This puts the entire system under duress.

Best practices:
  • Leverage application capabilities to accept multiple records in a single request.
  • Leverage adapter capabilities to send a large data set as attachements or files.
  • Use a stage file action and use apend file option to send the file to the destination.

2. Scheduled job that never stops trying to process:

Use case:
Process records within a set of files with a tight SLA.

Pitfall:
The scheduled integration looks for all files to process and loops over all to sequentially process until no files remain.

Why pitfall:
If a large number of files exist, one run of a sheduled job executes for a long time and starves other jobs and may get terminated by the framework.

Best Practice:
  • Limit the number of files to process in a single scheduled run.
  • Use scheduled parameters to remember the last processed file foe the next run.
  • Invoke the run now command to trigger processing of the next file if waiting for the next scheduled run is not feasible. 

3. Import an externally updated IAR file:

Use case:
Need to leverage advanced XSL constructs that may not be avaialble in the mapper.

Pitfall:
Updating the IAR file externally and then importing it into Oracle integration.

Why pitfall:
Activation failures may occure.
This can lead to metadata inconsistency and validation failures.

Best Practice:
Use import map feature in oracle integration.


4. Synchronous Integration doing too much:

Use case: 
A request triggers complex processing involving enrichment and updates across multiple systems.

Pitfall:
Huge synchronous integration modeling a large number of invokes/conditional logic.

Why pitfall:
Susceptible to timeouts.
Blocking call - holds resources and starves other integrationa.

Best Practice:
  • Explore moving completely to an asynchronous integration - fire and forget , async response. Thus it will alao support  resubmission of failures.
  • Optimise sync processing with a coarse grained external API to replace multiple chatty calls.
  • Split into a sync integration containing mandatory processing before sending out a response and triggering separate asyn fire and flrget integrations for other processibg logic.

5. Too many connections in an integration

Use case:
As developers create integrations, they define their own connectiona pointing to the same application. This leads to many duplicate connections.

Pitfall:
Every developer creates their own connection using different set of configurarions/credentials.

Why pitfall:
High number of connections make manageability painful, specially when you need to update the endpoint, credentials etc. 

Best practice:
Have a custodian create needed connections and ensure duplicate connections of the same type are not created. 
Build a best practice for naming conventions and maintaining a set of configurarions.



6. Read files with many records

Use case:
Read a file with a large number of records and process individual records.

Pitfall:
Reading the entire file in memory using the read file option and processing record by record.

Why pitfall:
Consumes large amounts of momory and impacts other system procesing.

Best practice:
Download the file to the stage location using the download file option. 
Use the read file with segments options. Platform automatically processes segments in parallel. Platform brigs in only the portions of the file to the memory, as needed.

7. Integrarions running unchanged despite changing business needs

Use case:
Integrations/schedules created during the initial implementation continue to run even though your business requirements have changed over time.

Pitfall:
Integrations and scheduled jobs created during the initial product implementation are never re-evaluated against changing business needs.

Why pitfall:
Unnecessary runs of jobs that handle no work.
Clutter with dead integrations, life cycle management overheads and developer confusion.

Best practice:
Periodically analyze existing integrarions or schedules against current business needs.
Deactivate integrations that are no longer needed.


TBD.

Reference: Common Integration Pattern Pitfalls and Design Best Practices


Featured Post

11g to 12c OSB projects migration points

1. Export 11g OSB code and import in 12c Jdeveloper. Steps to import OSB project in Jdeveloper:   File⇾Import⇾Service Bus Resources⇾ Se...