#1082 OIC moving to a quarterly update cycle

  

Here's the full text from the Oracle Integration blog - 

We’ve heard from many of you that a less frequent and more predictable release cadence would make it easier to plan and adopt new capabilities. 
To support this, we are simplifying the schedule and moving to a quarterly release cycle. This will begin in January 2026. 
Moving to a quarterly release cycle will give you more time to check out and adopt new features, while ensuring we continue to deliver innovation with the highest quality.

As part of this transition, we will be skipping the previously announced 25.08 release. 
So our next update will be 25.10, which will deliver exciting new enhancements, including many AI-powered capabilities.
25.10 will be our final release, before we begin our new quarterly cadence.

Thank you for your partnership as we continue to deliver capabilities that help you automate and innovate with confidence.

#1081 OCI Log Analytics - Leveraging LoganAI for OIC insights

I've been a great advocate of OCI Log Analytics for a very long time. As you all probably know, it is very easy to push your OIC activity stream logs to OCI Log Analytics. And there the magic begins!

LoganAI is a new capability that allows you to interpret your log data via a chat interface, i.e. no more need for constructing complex MQL queries - just ask and you shall receive!

For those new to OCI Log analytics, I suggest you check out the plethora of posts available here.

For those that want a deep dive into LoganAI first, then check out the excellent post from Kumar here.

All read up? Then let's start with the following project in OIC and the 4 order processing integrations we'll look at -

The integrations themselves are banal - the only one with any logic is validateOrder. 

All 4 integrations have the following tracking fields - orderNr, product, customer. 

I trigger a couple of instances of each integration - 

Now to OCI Log Analytics - 

I query on the OIC activity stream log group - 

'Log Source' = 'OCI Integration Activity Stream Logs' and 'Log Group' = My_OIC_LogGroup | fields -Entity, -'Entity Type', -'Host Name (Server)', -'Problem Priority', -Label, -'Log Source', -'Log Group' | fields 'Integration ID', OICStatus, Message | timestats count as logrecords by Integration | sort -logrecords

Notice the highlighted icon - 

It knows the type of log file were looking at, It tells me that the integrations are related to order processing and it suggests a couple of follow-up questions.

But I have my own questions - 

• did any integrations fail?

1 integration failed, validateOrder,  and I now have the identifier of that flow and also the reason for the failure - "Invalid Country".

• what is the orderNr of the failed instance? 

So orderNr 4 failed 

• How many orders did I process in the last 3 hours?

11 orders? now let me ask a more precise question - 

• How many orders were created in the last 3 hours?

According to OIC Observability -

What does Log Explorer show?

• what are the order numbers of the orders created in the last 3 hours?

• are there any duplicate order numbers for create order?

Looks like we have a duplicate - order nr 3.

• Did any orders fail validation? 

• Which order took the longest to fulfill? Please also return the orderNr.

• give me the orderNr of the order that was fulfilled fastest

• give me the order numbers of the orders that have passed validation, but have not yet been shipped

Yes, orderNr 2 has been validated, but not yet shipped.

Now I will look at the average execution time of the createOrder flows - 

I check one of the instances in OIC -

There are 2 ways to look at average here, depending on what you take as the starting point. For this case, I will use Wire Message received as the start event. Because this includes the internal wait time. The flow, shown in the screenshot, took 250 msecs.

• what's the average execution time of the createOrder integration? Use the Message Received action as the start event.

I'm sure you've got the idea at this stage.

Finally, I save the query in Log Explorer - 

I can now drill into this - 

and click the above icon to start the AI chat.

Summa Summarum

This is a great addition to the wider OIC Observability toolkit. Do check it out and see how easy it really is to drill into your activity stream logs.

Kudos to my OCI Log analytics colleagues Zubair & Kumar - well done guys!

 

 

#1079 OIC Activity Stream Tracing Levels and OCI Logging

This post details how OIC activity stream logs surface in OCI Logging. It also shows exactly what you will see in OCI Logging, depending on the trace level you select, when activating your integration.

The post also covers some of the possibilities you have for interrogating these logs in OCI Logging. 

Finally, we take a look at OCI Dashboards, which allow us to add widgets, based on OCI Service Metrics as well as the OIC activity stream, pushed to OCI. 

You can do a lot with this data in OCI Logging; pushing these logs from OIC, can also be a conduit to OCI Logging analytics. There you can create really powerful, actionable dashboards.

But today, it's back to basics - what do I get in OCI Logging, when I push the activity stream logs from OIC. Not only that, we will also take a look at OCI Dashboards!    

Let's start with a simple example - 

Our integration, shipOrder, has 3 tracking fields - orderNr, customerNr and productNr. Each of these are initially set to values contained in the request payload. The only logic in the integration is assigning the value "MyCustomer" to the customerNr tracking field.

Debug Level Trace

Check out the activity stream log messages in OCI Logging - 

This log entry format is essentially the OCI Logging view of the OIC Activity Stream, essentially a subset of the activity stream, you can download from OIC.

With the level set to Debug, you get the following log entries. Note, they are not in the order you might expect, but we can quickly fix this. 

Essentially, the entries are in descending order, from a time perspective.

So let's begin by setting the sort to datetime asc- 

The first entry contain the wire message (the request json payload).

The second, logs the execution of the  Receive actin, which actually initiates the flow.

Before looking at these in detail, let's first look at the generic structure of the activity stream log surfaced in OCI Logging. 

The datetime field is the execution timestamp for this entry, it is in epoch format. The time field, contains the converted version o this.

 

The log content is divided into 2 main areas - data, which contains the salient info related to the OIC execution step being logged and oracle, which contains tenancy, compartment ocids etc.

If the log entry is for a OIC action, such as Receive (OIC Trigger), you will see 2 fields in data - actionName and actionType. In our case, these have the values, shipOrder(the name given to the trigger) and Receive.  
 

So let's go thru these 1 by one - 

Wire message - 

Note the parentEventId = -1. This indicates a top level integration, i.e. an integration that has not been invoked by another integration.

We see the flow or instance id along with the integration and project ids - integrationFlowIdentifier & projectCode.

Note the opcRequestId - think of this as a guid, that would be passed to any integrations, invoked by this one.

Finally, the message field - this is a generic field, and, in this case, it's value is the request payload.

The second message is for the Receive action, which we've already looked at.

Now come the initial 3 message for the tracking fields -

These have the format -

The next messages relate to the Assign of the value "MyCustomer" to the customerNr tracking field -

Now to the next 3 log entries - 

The first of these is for message received by mapper -

The second - is for the assignment of the new customerNr tracking field value.

The 3rd message - data Mapping completed.

The final 2 log entries are for the response - 

The first one contains the xml representation - 

The second is json - 

Audit Level Trace

With trace level set to Debug we had 13 log messages, with trace level set to Audit, 10 -

The Assign action is not logged, for example. However, I still get the request and response payloads logged.

Ergo, Audit should be sufficient for most cases.

Production Level Trace

10 rows, but no request, response payloads logged -

However, tracking fields are logged - 

If required from a compliance or business perspective, I can use the Logger action to push fields, e.g. request payload fields, to the activity stream log surfaced in OCI Logging.

I mentioned earlier that what we see as activity stream logs in OCI Logging, is but a subset of what we have in OIC itself.

Here is an excerpt of the download of the activity stream log for a "production" trace run of shipOrder -

What else can we do in OCI Logging?

Firstly, how do I enable logging to OCI Logging? Simple, just click the Logs link in the OCI console page for your OIC instance -

I've already enabled such.

Here's another of my OIC instances -

As you can see, I've chosen a different log name.

I delete this log and then enable logging again - 

I could, if I wanted to, enter the log name used by the first instance -

Or else I could give a unique name to this log. Note, you can also specify data retention period via the advanced options -

I run a couple of integrations, so we've something to look at in OCI Logging. I've set the trace level to audit.

Now we're in OCI Logging. A couple of things to note here -

1. the ability to enter custom filters

2. the ability to specify which logs to search. The default is all logs in the compartment, so we will narrow this down.

3. time frame.

Let's begin by specifying our OIC activity stream log - 

I see the order number (310397) I just entered - 

Now, let's look at the custom filters - 

the simplest filter expression is just a string e.g. the order number 310397. I enter this value in the filter field and click return -

  As you can see, it has morphed into the expression - logContent = "*310397*" and naturally returns all log messages that contain that string.

I change the query to sort in asc order - 

and check out the results - 

I can also filter on the log file fields -

for example, give me all the logs for a specific integration - 

The filter also shows you the possible values - as I've only run shipOrder, that's all I see.

You can always click the advanced mode link to see the actual query. After a while you may find yourself using this more often than not.

Also note the ability to save searches -

We can make the search more interesting by filtering on customer - let's run the following first -

Note, you cannot edit saved search queries, so I start over again - 

search "ocid1.compartment.oc1.." |

data.integrationFlowIdentifier='SHIPORDER!01.00.0000' and data.key='customerNr' and

data.value='Commiskey Inc' | sort by datetime asc

 

Net, net, you can make these queries as simple or complex, based on your observability requirements.

I can search for the combination of customer and product -

logContent='*Commiskey Inc*iBike*'

I mentioned earlier that OCI Logging can function as a conduit to other OCI services. for this you use connectors.

I have already created a connector to OCI Logging Analytics. The other possible targets are -

Object Storage could be used to push OIC logs to 3rd party monitoring apps, such as Grafana etc.

Finally, from OCI Logging, we can
directly navigate to OCI Dashboards.

OCI Dashboards

Dashboard usage is very intuitive.

We will build our first dashboard from scratch - 

The following widget sources are relevant from an OIC perspective - 

This simple widget can tell you your top integrations from a billing perspective.

I also added a widget based on the OCI Service Metric - NumberOfInboundRequests

Here I can create a widget, based on my saved search -

From here we can drill into the log using Log Search -

The base query for this doughnut (yes, this is the correct spelling) is - 

 

Summa Summarum

Naturally OIC itself provides a plethora of features in respect of Observability. However, OCI Logging is a great value add to that. It allows folks who only have access at OCI level to monitor what's running on OIC. This may fit in nicely with segregation of responsibilities etc. It also allows us to create dashboards combining data from OCI Service Metrics for OIC as well as data from the activity stream logs, pushed to OCI. 

If I've whetted your appetite for more, then please check out these posts on OCI Logging. 

I've also posted on leveraging OCI Logging Analytics for OIC Observability; those posts are available here.