OIC Gen 3 - File adapter vs FTP adapter

OIC Gen 3 - FTP does not support polling as trigger then what is the alternate solution to achieve FTP Polling?

What: FTP Adapter does not support polling as a trigger.

Alternate solution: follow the below steps

1. Take a scheduled integration
2. List files as invoke
3. If list count >0
4. Download file to stage
5. Process files to downstream apps.

Note: File adapter supports polling file as trigger to shared file system.

OIC Gen 3 - Max file size supported by Rest, soap, file and ftp and database adapters | Service limit

The max file size supported by rest, soap, ftp, file and database adapters as below:

Rest Adapters: 

• Structured message for trigger and invoke: 100mb
• Binary or attachments: 1GB
• With connectivity agents: 50mb

SOAP Adapters: 

• Structured message for trigger and invoke: 100mb
• Binary or MTOM , attachments: 1 GB
• with connectivity agents: 50mb

FTP Adapters: 

• Structured message for trigger and invoke: 100mb
• Binary or without schema: 1GB
• with schema and connectivity agents: 50mb

File Adapters: 

• Structured message for trigger and invoke: 50mb
• Binary or attachments: 1GB
• with connectivity agents: 50mb

Database Adapters: 

• Trigger or Polling (schema based):  50mb
• Invoke database select: 100mb
• Invoke store procedure / operation on table / run puresql operation with schema transformation: 10MB
• With connectivity agents: 50mb

Reference:

https://docs.oracle.com/en/cloud/paas/application-integration/oracle-integration-oci/service-limits.html

OIC Gen 3 - Data Stitch action

Data stitch operation types:

1. Assign : suppose , you use a invoke inside a scope and want to take the invoke variable data to outside of the scope, that case mainly we use assign.
2. Append : suppose, we have a scenario , where we need to incrementally build a message payload or partial update of the payload.
3. Remove : to remove some data from an existing payload.

Assign:

OIC - Global variable and Data Stitch action using assign operation

Append:

OIC - Append operation in Data stitch action | Incrementally build a messags payload using Data stitch

Remove:

TBD

OIC Gen3 - about actions

 How to Add actions:

1. Open the actions pane
2. Use the inline Menu

List of actions available:

OIC Gen 3 - Working with XSLT constructors

If we open toggle function pallet, by default we would not see the XSL constructors, we have to click the XSLT button to enable to see it.

If we drag the xsl statement and hover or drop it in front of the element, then it will be added as child component of the element.

If we drag the xsl statement and hover or drop it at the back of the element name, then it willbe added as parent component of the element.

Note:

• Select If statement to specify single condition
• use choose when otherwise to specify multiple conditions. 
• For looping logic, use for-each statment. 
• We can also use xslt output >> literal, text, attribute, copy-of and value- of  to set default values in the mapper. 
• Using a copy-of element, we can perform a deep copy of elements from source to target with a copy-of constructor if both have same set of elements.

Xslt code editor use cases:

• Create internal variables
• Correlate multiple data  sources grouped by key field using the xsl for each group constructor.
• Create target name value pairs.
• Implement push style xslt (call template, apply template)
• Write custom xslt functions
• Copy node sets

Edit xslt code in oracle jdeveloper:

• Export the code.
• Design the integration flow logic
• Open the empty map action
• Map one data value from each required structure to the target
• Validate and clodw the mapper
• Save and the close the integration
• Export the entire integration archive (.iar file), for projects export the .car file.
• Import the iar file oracle jdeveloper
• Create an OSB application and project
• Import the integration archive to the osb project.(service bus resources >> select zipped or archived files >> selct file >> import.
• Locate and open to edit the .xsl file
• Import the .xsl file(not the entire integration) back to the oic mapper.

OIC Gen 3 - Error handling | OIC Error Hospital | Global and scope level fault handlers | Fault and End actions

Why we need to implement error handling / designing beyond the happy path:

• What happens When don't implement fault handling logic of any kind. By default every error occurs runtime, deliver to the OIC error hospital which is part of the oic runtime environwmnt, hosting all your deployed integrations, this can include any faults like runtime or business faults, request timeouts, invalid payloads, internal error etc.
• When error hospital catches a fault,  the integration flow stops or terminated immediately
• If you work on the projects, it will show on the observe page.
• If the integration is sync app driven and fault happens, the error hospital sends the same fault details to the client.
• All the errors are visible in the visibility secrion >> error page.

Instead of allowing the error hospital to catch every fault, we can intentionally catch all fault using the global and scope fault handlers.

Best practice Examples of error handling:

1. Log the error but continue with the integration flow.
2. Invoke a secondary service for backup processing.
3. Log the error and then terminate the integration flow
4. Invoke another service for notification or error handling processing.
5. Reply to the integration glow's client with a custom error response.
6. Send an email notification to an external stakeholder or an internal administrator.
7. Invoke an OIC  process to initiate a process workflow involving manual intervention.

Implementing Global Fault handler:

1. By default, there is default global fault handler, where it has re-throw fault action which rethrows the fault to OIC error hospital.
1. All uncaught faults and errors go to global fault handler
2. Throw new fault from scope fault handler
3. Re throw fault from scope fault.handler.
2. Change the default handling logic apt for your integration like 
1. add logger, 
2. email notification.
3. Map custom data for a fault return for sync integrations
4. Mitigate the error contion with alt logic
5. Invoke an error handling service(another oic integration or external service)

Global fault handlers End actions;

1. Re throw fault : it will send the fault to error hospital, 
2. Throw new fault: it will send a custom fault details to error hospital
3. Stop:  Terminate the integration flow, no error hospital will be involved. Separate fault handling logic wii be there before the stop action.
4. Fault return:  explicitly sending the business faults to the client for sync service. No error hospital is involved.
5. Return : fault mitigation logic, invoking a backup service, then send the normal.data to the client. No error hospital is involved.

For each invoke , try to create a scope and define scope fault handler.

Faults occurring within handlers are caught up by the next higher handler.

Inner scope >> outer scope >> global >> error hospital

Scope or global fault objects will be created to fetch fault details in the failt handler.

Note: 

For my project, I have followed as below:

1. For each invoke>> take it in one scope and in the default fault handle >> throw new fault with code, reason and details.
2. In global fault handler >> we have send the the global failt details to data dog SaaS application for further support.
3. We have created a lookup like common_error_details_lookup where it captures the key, error type, error code, reason and details. Using the key like 'UCMUPLOADFAILED' we can fetch custom error details.