Oracle Fusion MiddleWare Blog: ICS

Showing posts with label ICS. Show all posts

Saturday, 4 February 2017

Oracle Integration Cloud Service (ICS) Coding Standards

Naming Convention for {Source/Target}-SOAP or SOAP-{Source/Target} based Integrations

· Naming conventions for the Connections

Syntax:

Example:

Sample-SOAP-ReceiveAccount-SFDC

· Naming conventions for Integrations

Syntax:

Example:

Sample-ReceiveAccount-SFDC

· Naming conventions for Identifier

Syntax:

Example:

SAMPLE_RECEIVEACCOUNT_SFDC when Target is SFDC

Naming Convention for {Source/Target}-{Source/Target} based Integrations

· Naming conventions for the Connections

Syntax:

<ProjectName>-<AdapterName>-Conn

Example:

Sample-Salesforce-Conn

· Naming conventions for Integrations

Syntax:

Example:

Sample-Sync-OSC-Account-SFDC when source is OSC and Target is SFDC.

· Naming conventions for Identifier

Syntax:

Example:

SAMPLE_SYNC_OSC_ACCOUNT_SFDC when source is OSC and Target is SFDC

· Naming Convention for lookups

Must start with the Object Name / Business Entity Name.

Should be followed by the Element Name that needs domain value mapping.

Must be uppercase.

Syntax:

Example:

ACCOUNT_THEATER.dvm

Description: Lookups created will be used inside the Integrations.

· Better Readability

Proper description to be present at each level of Integration, lookup's for better readability.

Reason: Clear description prevent us from creating a duplicate integration and helpful in re-usability.

Thank You!!!!

Happy Learning!!!!

Oracle Integration Cloud Service (ICS) Best Practices

1. Proper Versioning of Integration should be maintained

Example: 01.00.0000

Reason: Service versioning defines the strategy for having multiple versions of the same service to be operational at same time so that changes and enhancements to service interface do not affect existing consumers.

2. Integration should be inside Package.

Syntax: <CompanyName>.<ProjectName>.ics.pkg

Example: xyz.sample.ics.pkg

Reason: All Integration which are included in the package can be imported/exported in one shot from one environment to other environment.

Issue: If we won’t give the package name the integration will be created as normal integration without package and it will be a miss when we migrate integrations of project which are present in specific package from one environment to other and manually we have to move that particular integration.

3. Fault Mapping Should be done for every integration of map to data and Global Fault should be added for orchestrated integrations.

Reason: For proper debugging, get exact details of the error and to check where exactly integration has failed. If we don’t implement this, we are not aware where exactly the issue is and it will be time consuming.

4. All three Business Identifiers for tracking should be provided (Primary Id of Business Entity, Name, Cross Reference Id) and make one of them as primary according to the business functionality.

Reason: It will be helpful for easy tracking, when issue comes immediately we can get into details and take necessary actions without time consuming.

5. Check for NULL values before assigning mandatory fields.

Reason: Checking the validation before sending the data to Target System which will reduce unnecessary calls with improper data.

6. Filter condition has to be implemented for events while configuring Adapter endpoint in integration to avoid same event firing continuously.

7. Copy-of in ICS Mapping:

Template:

Use when source and target has same WSDL (Including namespaces).

Reason: It will be helpful even if new elements have been added in the end systems, no need of mapping changes in integration and just what we need to do is a meta data refresh on connection and on the integration created.

Value-of in ICS Mapping: