OIC - Add Header or line file field names with easy method

Sometimes when we send FBDI files to ERP/HCM or other applications, we may also need to share the header or line field names to the file itself. To add huge number of field names manually is a hectice process. But there is option to easily we can add the field names. See thr below steps.

Steps:

Step1: Take a stage activity and write file operation and privide file name, virtual stage directory and select append to existing file.

Step2: provide a sample csv file with one field name and select Use first row as column headers.

Step3: add all the fields as comma separated within double quotes to target field .

And its done.

ODI 12c - Stop and Start ODI Instance from OCI console

Here, We will see how to Stop and start ODI server instance on OCI

Steps:

Step1: Login to OCI console with the account 

Step2: After login, click on Hamburger and navigate to instances

Step3: Select the appropriate compartment

Step4: It will show all the available instances. Select the instance to restart.

Step5: Use Stop button to stop the instance and Once status says "Stopped" we can restart using "Start" button.

Use below useful commands whenever needed:

"systemctl status agentodi.service" -- To check if its disablwd or not.

"sudo systemctl daemon-reload" 

Path of ODI studio: /u01/oracle/mwh/odi/studio

To restart odi normally "./odi.sh"

To restart odi in clean way "./odi.sh -clean -initialize"

ODI 12c - Scheduled jobs and load plans executed twice by agent after instance restart

This issue occurs for the following reasons:

• The instance was restarted without the agent being stopped first.
• The agentodi.service is active even after the management service was moved to the multi-app Jetty service manageappsodi.service. since the agentodi.service is active , it is causing a second agent to start resulting in schedule duplication .

Solution:

When the agent is stopped gracefully, this issue is not observed in ODI on Marketplace version 12.2.1.4.210321 or higher.

Ensure to always stop the agent gracefully anytime before restarting the instance.

Disable the agentodi.service

Log in to the compute VM instance using the opc user using putty or from command line:.

ssh -i <private key> opc@<ipaddress>

Issue the following commands for disabling the agentodi.service:

sudo systemctl disable agentodi.service

sudo systemctl daemon-reload

Reboot the instance and test the scheduler behavior.

ODI - Changing ODI Schedule

Step1: Go to Operator -- Scheduling -- select your load plan and Global/logical Agent -- right click on it and open /New to update or to create new schedule respectively.

Step2: Update Agent schedule:

Go to Topology -- Agents -- Right click on OracleODIAgent and click update schedule

ODI - Steps to restart ODI Agent

Using ODI on Oracle Cloud Marketplace: 

Step1: Go to Terminal(Here, Applications --System Tools -- Terminal)

Step2: Navigate to the script location:

$MW_HOME/odi/common/scripts

Here, cd /u01/oracle/mwh/odi/common/scripts

ls

Step3: Run the command to shutdown

python manageOdiApps.py shutdown

Step4: Run command to start the agent:

Nohup python manageOdiApps.py start &

To see the logs run as below:

tail -f nohup.out

Ctrl +C to come out

Step5: Run the command to restart the service:

python manageOdiApps.py restart

Step6: Check Status

python manageOdiApps.py status

Step7: Test agent from Odi studio

Go to Topology -- Agents -- Right click on OracleODIAgent and click test.

OIC -OOTB Error handling in easy steps

 Fault handlers:

• Scope level
• Global fault

Scope level:

Scope level fault handles are used to handle errors that arise during the invoke actions within those scopes. It handles the faults following 2 ways:

Implicit/specific fault handlers:

Depending on the type of invokes we used like Database, soap, ERP and etc. there will be a set of specific faults provided in the OIC in the scope level. It is like specific catch block. Each implicit fault handler will handle specific type of faults like APIAccessErrorFault, ServerErrorFault, UnexpectedErrorFault etc.

Default/Generic fault handler:

A default fault handler is generated for every scope which acts like a catch all block for that scope. Any error that is not handled by one of the specific or implict fault handlers will be handled by the default fault handler.

Global fault handler:

Global fault handler is available at the overall integration flow level which acts as a super catch block. Any errors unhandled at the inner scopes or errors encounterd in non-scope blocks will be bubble up to this Global fault handler.

Note: 

1. If you dont want to define or configure any implicit fault handler then define the default fault handler as that acts like a catch all.
2. If you dont use any fault handler, it will go to default handler called error hospital and the instance will be marked as failed.
3. Some cases, we can catch the error defining the fault handler and send the error details to the caller / mail integration and marked the called sub integration as completed.

OIC - About Virtual File System(VFS)

Virtual File System:

• The Virtual file system (VFS) enables us to store files and internally use references to these files in the message payload.
• We can also map the VFS file's content to a string element.

For example,

• The FTP adapter uses fileReference for reading / writing a file without a schema. fileReference is also a reference to a file stored in the VFS.
• The Rest adapter supports the multipart attachment and application/octet-stream features. The attachment is stored in a staging area and an attachmentReference is generated. The attachemntReference key is sent as part of thr message payload and latet fetches the attachment instance from the staging area.

Map the content of a staged file attachment toa string element by converting the content to a base64 string. 

Following 2 xpath functions are used:

• encodeReferenceToBase64(String reference): input - the reference and Output - base 64 encoded content of the file.
• decodeBase64ToReference(String base64String): Input - base64 encoded value and Output - reference or location of the file.

Available reference or relative path:

• fileReference
• attachmentReference
• streamReference

When an attachment is stored in the vfs, a key is generated to retrieve the attachement later time. The key is shown in the mapper as attachementReference/fileReference/streamReference. The key is propagated with the OICS as part of the payload. For rest adapter streamReference is used. For FTP fileReference is used. Depending on the adapter type, the appropriate reference gets created.  Using the reference , we can fetch the content of the file and use or map the content as needed.