#1163 - OIC - Time Taken Analysis

Introduction

My esteemed colleagues at OCI Log Analytics have provided me with the updated version of the OIC Time Taken Analysis dashboard, which should be generally available soon. 

Let's check it out; here are the integration flows we will be analysing - 

The integration is, as usual by my posts, very simple - 

The only logic being a WAIT of 30 secs, when orderNr = 123.

Now to the new dashboard - 

Time Taken Analysis Dashboard

I realise the screenshot is small, so look at the different sections - 

Filters

Here you can filter on - 

• OCI Compartment
• OIC Instance
• Integration

Regarding 'Entity' this is essentially a duplicate of the OIC Instance filter - 

I will be asking the Log Analytics team to remove this, as it tends to confuse folks.

Analysis Widget

The X-axis represents the time taken, the Y axis the integration selected.

I ran the integration 4 times, but, as you can see, this results in 4 groups, from time taken to execute perspective.

Here are the execution times from OIC Observability and the resulting widget groups -

We have 3 groups of log data, each group essentially represents an integration flow). The times are between 16 and 61 msec.

Then we have the anomaly - 

As you can see, the 30.07 secs from OIC Observability has been rounded up to 30.1 secs.

The Table Data

Here we see the 4 groups, grouped by instanceId -

Note, the instance ids are shown in lower case; in OIC itself the case is mixed. 

The Count refers to the number of log messages for the flow. The first instance has more log messages, due to it executing the WAIT. 

Other functionality here includes the ability to leverage LOGAN AI - 

We can also punch out to Log Explorer - 

Here you can drill down into the logs - 

You can, of course, also change the underlying query, add new fields, change visualisations etc.

 Back in OIC, I clone process order and create delete order and update order. I then run this a couple of times - in total 14 flows. 

The Dashboard view - 

Not filtering on a specific integration let's me see what's happening overall. This could be useful, when troubleshooting anomalies; for example, multiple integrations trying to invoke the same resource etc. Naturally, this is not viable, if you have many different integrations running simultaneously.

Summa Summarum

This dashboard will be a very useful addition to the set of OIC dashboards, shipped with OCI Log Analytics. The added abilities to explore further using natural language via LOGAN AI, and drill deep into the logs via Log Explorer make it even more compelling.

Cerevisia Aestiva

Today's beer is a Czech lager, in a totally different league to it's US namesake - 

Set up in 1895, to provide a Czech alternative to German beers, this brewery has gone from strength to strength. The lager is 5%, with the right amount of crisp bitterness. A true delight compared to Bud Lite.
 

 


 

#1162 - Use of Semaphores in OIC Part II

 

Introduction

This post looks at implementing the singleton pattern via semaphores. It leads on from the previous post, which you really should read, before continuing.

The use case is very simple - an async integration that can only run as a singleton.

Here is the integration - 

As you can see, the singleton rule applies to the createOrderScope, Commiskey Inc. is an old fashioned company that likes creating orders for our craft beers one at a time.

I acquire the semaphore before executing the createOrderScope. It is released, on completion.

The only logic I have in the scope is a WAIT and a LOG; the LOG outputting order creation time.

As mentioned in the previous post - channel and name are unique. So, for this use case, I can hardcode them in a lookup - 

I use the instanceId as the requestor -

The instanceId can be found here - 

I'll invoke the integration twice, with orderNr set to 2112 and 2113 - 

Let's check the instance ids - 

Let's check the timestamps for order created -

Here we see the 30 second delay - 

I'll run again to get some screenshots from the Semaphore control, this time with orders 2525 and 2526 - 

Here the holder is set to the instance id of the flow for orderNr 2525.

Note we have 1 message in the backlog - 

Here we see the acquire request from the orderNr 2526 flow.

Ca. 30 seconds later - 

The 2nd instance has acquired the semaphore.

The 2nd flow has released the semaphore.

Here's the view from the acquire and release semaphore side of the house - 

As you can see, the first acquire only took 1.2 seconds. The 2nd, 26.37 seconds - 

For the 2nd instance - note the WHILE loop - executing until the semaphore can be acquired.

Summa Summarum

This is a simple POC, but it does illustrate what can be achieved. Note, the acquire semaphore integration is synchronous, so one needs to be aware of possible timeouts after 5 minutes. However, this could still be useful for many use cases.

Cerevisia Aestiva

This brewery, from the old town of Neumarkt in the Oberpfalz, has been going since 1628. It is still family owned and prides itself on only using organic ingredients in its beers. They produce bottom-fermented beer as well as top-fermented beer. The latter uses Saccharomyces cerevisiae yeast, while the former uses Saccharomyces pastorianus yeast. Bottom-fermented beers are your Pils and Lagers, while top-fermented beers are your Weissbiers, Ales and Stouts of this world. Bio Urstoff is the one I tend to drink - a perfect mix of hops and malt.   





 

#1161 - Use of Semaphores in OIC - Part 1

Introduction 

Semaphores, within the context of software, can be used as synchronisation tools to manage how multiple processes access a shared resource.

OIC related use cases could include - 

• FIFO
• Synchronisation between async integrations
• Singleton
• Scatter/Gather
• Resequencer
• etc.

This post will document a simple implementation of using semaphores to enable synchronisation between 2 async integrations. My 2 integrations are async create order and async create customer. The rule is simple - an order can only be created for an existing customer. If the customer does not exist in the customer DB, then async create order has to wait until async create customer does the necessary. 

Before I begin, a BIG Shout Out to my very esteemed colleague, Antony R. for the initial idea. He also set up the whole semaphore / OCI Cache infrastructure and provided the 2 key integrations - acquire and release semaphore.

Let's begin with the semaphore implementation.

The Semaphore Implementation

This is the python based UI we will be using.

Underlying this is OCI Cache - 

More about the cache in a later post; now lets proceed to the 2 semaphore integrations - acquire and release -

I will not go into detail here, suffice to say, one acquires and the other releases the semaphore. 

The Create Order Use Case

Here are the 2 async integrations -

async create order

This integration does the following - 

• Check if customer already exists
• If yes
• Create order for customer
• If no
• Acquire semaphore
• Invoke async create customer
• Payload will include semaphore details
• WHILE Semaphore not acquired
• Attempt to acquire the same semaphore again
• If Acquired 
• Create order for customer
• Release semaphore
• Exit WHILE 

The request payload is - 

{ "custFirstName" : "Niall", "custLastName" : "Commiskey", "custCountry" : "Ireland", "product" : "iBike", "price" : 4999 }

async create customer

This integration does the following - 

• Create customer in customer DB
• Release semaphore

The request payload is - 

{ "firstName" : "Niall", "lastName" : "Commiskey", "country" : "Ireland", "channel" : "Create Customer", "requestor" : "OIC" }

Acquiring the Semaphore

The request payload for AcquireSemaphore is as follows - 

{ "channel" : "channel", "stream" : "stream", "requestor" : "job-17", "timestamp" : "2026-07-10T17:00:00Z" }

So what's the unique key here? It's the combination of channel and stream.

For this simple demo I will use the combination of firstName and lastName as the stream. I will call the channel Create Customer.

I have added the following lookup to the project -

Note the different requestors, we'll see how they are used presently.

Releasing the Semaphore

The request payload for ReleaseSemaphore is as follows - 

{ "channel" : "channel", "stream" : "stream", "requestor" : "job-17" }

Implementing async create order 

Check if the customer exists.

If found, store the customerId in a variable.

Otherwise, acquire the semaphore, 
setting requestor to the lookup value for requestor-pre-cust-create - OIC-CreatingCust.

I then invoke the async create customer integration. This integration will create the customer in our ATP powered customer DB and then release the semaphore.

I then try to acquire the semaphore, but this time using the requestor - OIC-CreatedCust. We will continue in the WHILE loop until the semaphore has been released by the async create customer integration. 

I get the customerId of the newly created customer and release the semaphore.

The final step - 

Let's try this out.

Running the Use Case

Pre-checks

No semaphores - 

No customers / orders -

Check out the screenshots below to see how the semaphore is processed - 

Semaphore created with the holder OIC-CreatingCust

There is a backlog - OIC-CreatedCust trying to acquire CreateCustomer / Phillip Commiskey

The semaphore has been released, so now OIC-CreatedCust can acquire - 

The async create order integration has released the semaphore -

Check the Customer DB - 

Summa Summarum 

This is just one case where semaphores could be applied. As stated in the introduction, others include - 

• FIFO
• Singleton
• Throttling

More about those later.

Cerevisia Aestiva

Today's beer is another gem from Franconia. 

The Hofmuehl brewery is located in Eichstaett, about 60km away from where I'm living. The town is famous for its Catholic bishopric and it was a bishop who founded the brewery in 1492. The Securalisation laws from 1803 resulted in the state taking over the brewery, but it passed through many hands since then - including Eugène-Rose de Beauharnais, the adopted son of Napoleon Bonaparte.

Their Helles is 4.9% - a light, hoppy beer, great for hot summer evenings.