#1027 Simple demo of OIC3 RPA

OIC3 RPA was a HUGE hit at Oracle Cloud World last month. Our customers who attended see this as an extremely useful and salient addition to the OIC3 toolkit. I suggest you read the excellent blog post from my colleagues on this topic as it gives you a high level overview of what RPA is and why we are doing it.

Check it out here.

Introduction 

My post will deal with the mechanics, so let's begin with a very simple use case. I will use the robot to login to an app from the US Postal Service and get the 9 character zip code for a specific US address - 

RPA in OIC3 Projects

Note the new RPA section in OIC3 Projects - 

Robots – orchestration - what the robot needs to do e.g. login to an app and get the Zip code for a specific address

Environment Pools – link to the agent or pool of agents that run(s) the robot

Robot connections – URL and credentials for the target app(s).

Robot Agents 

The robot agent is the one that does the actual work, i.e. executes the robot orchestration we will define.

Agent is downloadable from OIC3 - 

I've downloaded the Robot agent to my laptop, started it and see it's waiting for work -  

Robot Connections

Here we specify the URL, credentials etc. for the target app. In my case, it is as follows - note, user /pwd are not required for this specific website so I just enter admin/admin.

Environment Pools

Again, think of this as the link to the RPA agent. i.e. in Robots I define what needs to be done and in Environment Pools I can include 1 or more environments (RPA agents) which will be doing the execution.

Robots

Now to the robot orchestration - the scenario is as follows - I have 2 fields as input - street address and 5 character zip code. I will pass these to the robot and instruct it to open the USPS website, enter the 2 fields, press the Find button and then extract the 9 character zip.

The orchestration will be generated by the recording I will do. First step is to open the USPS app in my browser - 

I define the 2 input fields and 1 output field, before I start recording - 

  

I continue, entering the 5 char zip code and then pressing the Find button. This returns the 9 character zip, which I then extract and save to the output field I defined previously.

The generated orchestration is as follows - 

Note how each of these actions can be edited - 

I can now add the robot to an environment pool and activate it - 

Robot agent receives the request - 

I can track progress -

Activity Stream à la Integrations - 

Back in the Robot Designer - I add a Log activity to log the 9 character zip returned - 

Note the plethora of actions available, more about them in future posts.

I also add a screenshot - 

I re-run the robot - 

Here is the screenshot - 

Now, I realise this is a very banal example, but it does cover the mechanics of it. 

RPA is another tool in the OIC toolkit and here's where the magic happens. I can easily invoke the robot from an integration. In my example, I have a REST trigger that accepts in a JSON "customer" payload, including the fields street address and zip code.    

All I need to do is Map - 

I then set the integration response to the result from the Robot invoke, i.e. the 9 character zip.

I run the integration - 

Summa Summarum

Granted, the use case I've covered is banal, but I hope it does give you an insight into how RPA works within OIC. Robots are usually used when there are no apis to invoke to perform a particular task. However, robots can also be used as a tactical response to use cases that require the invocation and orchestration of multiple apis to achieve something that can be easily achieved via the UI.

OIC3 RPA is currently not officially GA, but you can ask for access via an SR.

Anyway, I've always loved robots since that seminal album from Kraftwerk - 

 

#1026 - OIC REST API Log file download - How To for OIC3

 

This OIC Gen2 api lets you download -

• ICS Diagnostic Log
• ICS flow log
• Audit Log

The request format is as follows - 

https://oicpm-oicpm-px.integration.ocp.oraclecloud.com/ic/api/integration/v1/monitoring/logs/log

The valid log values are -

• icsdiagnosticlog
• icsflowlog
• icsauditlog

Download the Diagnostic Log

I now download the diagnostic log and see the following, when I unzip it -

 

Note the structure -

The following files are weblogic specific -

• access.log
• oic_server1.log
• oic_server1.out
• oic_server1-nodemanager.log

As you can see, this is essentially of little use to an OIC admin.

Now to the ics-flow.log - 

It does contain OIC relevant data e.g. 

 

ActionID:y0][ActionName:InvoicesToATP][ActionType:Return]: Response received from InvoicesToATP

[2024-09-09T16:45:09.088+00:00] [oic_server1] [NOTIFICATION] [] [oracle.ics.trace.soa.bpel] [tid: 102] [userId: niall.commiskey@oracle.com] [ecid: d505d8d9-9d4e-48cb-9f6f-ee1c4a2edd04-002e7192,0] [APP: soa-infra] [partition-name: DOMAIN] [tenant-name: GLOBAL] [FlowId: 0000P7NfC8v5uXdLxe4EyW1anhva0002yu] [oci.instanceName: OICPM] [oci.identityDomain: identityDomainName]  [ICS Activity Stream Logging]: [Code:INVOICESTOATP][Version:01.00.0000][Instance:62405859][Operation:execute][ActionID:y0][ActionName:InvoicesToATP][ActionType:Return]: Integration execution has completed

However, it's not that readable.

Same applies to the oic_servern_diagnostic.log -

I'll skip the nodemanager log as that is pure weblogic.

Net, net, these logs are useful for checking out engine errors, but are not useful from a compliance perspective, e.g. these files don't help you prove that orderNr 123 was processed on a certain date.

Download the ICS Flow Log

The Structure of the downloaded zip - 

I executed the following simple integration, before running the REST request -

Now I activate the integration with trace enabled - 

I download the log file again, and now I see the payload in the log -

Net, net - the ICS flow log is useful, when you enable tracing / include payload.

Download the Audit Log

This log details who did what in the designtime -

e.g. here my activation of the integration has been audited - 

[2024-09-25 13:29:17.577] [userId: niall.commiskey@oracle.com] [niall.commiskey@oracle.com,ACTIVATE,ICS_ProjectV2,AA_SIMPLE_SYNC_WITHCHIL,AA-Simple-Sync-WithChild,01.00.0000] User niall.commiskey@oracle.com activated Integration AA-Simple-Sync-WithChild 01.00.0000

[2024-09-25 13:29:17.361] [userId: niall.commiskey@oracle.com] 

So now we have looked at what's available from OIC gen2.

Let's turn to OIC3.

OIC3 Retrieve Audit log

Note the structured format of the response, easier to read and process, compared to OIC Gen2.

The following OIC3 api can be used to retrieve instance flow details, similar, but not the same as the OIC gen2 ICS Flow log. - 

The response is as follows - 

As you can see, even in debug mode, the request payload is not returned.

What we do see, however, is the tracking fields and their values.

So how can we retrieve the integration flow request payloads?

First, let's take a step back - 

Customers usually use the OIC gen2 log api on a daily basis, for example, run the job to download the ICS flow log on a daily basis and push the response to a monitoring / analysis tool such as Splunk.

So, from an OIC3 factory api perspective, I could do the following - 

1. Retrieve integration flow instances for the time period e.g. for the last day.

2. For each of those instances, retrieve the request payload.

Let's look at 1 - 

note the id returned - 

that from the screenshot is as follows - 

na1TEHvfEe-BH8NDEl59ew

I will now use this to retrieve the payload via the activity stream, this is task 2 -

 

 

Final step is to automate this with OIC. Here I create a scheduled integration that will invoke both apis. In my simple demo, I will write the instances + payloads to a file.