Oracle SOA Suite 12c is now quite a while present on the market, offering a various set of adapters to choose from. In this blogpost, you’ll get a bit more familiar with the so-called Coherence Adapter. You will find essential steps to get started with this adapter and the local cache, and I will also provide a workaround for the cache invalidation.
Why Coherence Adapters?
The Coherence Adapter can basically be considered as a SOA-internal, in-memory cache to store a collection of data objects. The data type can be defined by a custom schema or alternatively by the wizard upon creation. Once you restart the servers, the cache data will be erased as well. This can be used for any kind of data, which doesn’t need a persistance layer on the long run.
A project for one of our customers required the use and refresh of an OAuth Token for the new backend system. One endpoint was called to fetch the token, which was used for authentication in a second endpoint. The frontend application called up to a dozen services simultaneously, so we had to cache the token to improve our overall performance. Due to a strict timeline and also restrictions on the accessability of the SOA servers (we had none), we set up the Coherence adapter with the local cache. The use of the local cache didn’t needed any additional configurations on the server or the weblogic, but it lacked in cache invalidation. All data stored within the local cache is only erased by restarting servers or by explicitly deleting the entries.
In order to overcome this shortcoming, we provided our own solution to refresh the cache entry. But first things first, let’s apply the Coherence Adapter to your SOA composite.
Coherence Adapter Setup
1. Adapter References
Before we start, it is important to know that the Coherence Adapter is working in different operation types. Upon creation, you have to choose one of them. This results in one Coherence Adapter reference for each operation type which you want to use: Put, Get, Remove or Query.
Though the operation type Query could handle all of the given operation types, we will rather choose a more simpler and transparent approach.
In your composite.xml, right-click the right swimlane „External References“ and select Insert → Coherence. This will start the Configuration Wizard. Give the reference a name (e.g. coherence_GET) and click on next.
In the next window, we need to provide the JNDI name for the Coherence connection. Since we use the local one, our JNDI name is „eis/Coherence/Local“. Click next to choose GET from the different operation types and click next again.
In the next window, select „adapter-local“ for the cache name. This is the preconfigured cache which we can use right off the bat. Leave the Key field blank and click Next. A popup will indicate you that we have to add the key later on for the header jca.coherence.Key, which we will add in a later step.
For the last step we define the used Schema file. This can be an existent one or generate one with the Native Format Builder. In the example, a new one was created from a JSON sample with userId, token and timestamp.
Repeat the steps for PUT
In order to also feed the cache with our data, we have to apply the same steps as mentioned above for the PUT operation type. You have to adapt the following changes:
- Name the reference coherence_PUT (at least distinct to the GET)
- Select Put for the operation type
- When you can provide the cache name, there is also a checkbox called „Auto-generate Key“. Make sure that this box is unchecked! We provide a custom key here.
- You can also ignore Time To Live here, since our local cache won’t be invalidated by default.
- For the message Schema, select the previously created Schema for coherence_GET
If you followed the steps above, you should now have two references for the Coherence Adapter – one each for read and write purposes. This is our basic setup, now it is time for action.
Consume both of the generated references from your BPEL of choice, we will now interact with them.
2. Consuming the Cache
Do you remember, when we left out the Key property in our Adapter references? We now add the key as a property in our Invoke actions (for GET and PUT as well). As a value, you should add a unique key which will be used to check your cache data and also update it. In the sample, we use the provided userId.
From here on, the following steps are familiar. Invoke first the coherence_GET to check wether some data was cached. If this is the case, return it to the user. If not, create a new dateTime, a new token (UUID) and add the provided userId to call the coherence_PUT.
3.Cache Invalidation – A workaround
Up to this point, we would be ready to use the cache. Unfortunately, it is always valid. In order to invalidate it, we added the timestamp to the cache value. This timestamp will be checked against the current dateTime and a custom time period (let’s call this offset) of your choice. If the token timestamp added with your custom offset is set in the future (after the current dateTime), this means the token is still valid and its data can be used. If this is not the case, you generate a new token, store it in the cache and process the newly generated data for further processing.
Depending on your demands, this can either work as a flexible variable or, as in the case of the provided sample, passed in from a config plan.
4. Last Steps
The last thing to do here are the last configurations from the WebLogic Server Console. If this is your first time working with the Coherence Adapter on your server, the CoherenceAdapter is set to installed by default in the deployments overview. You have to target the Adapter to the appropriate server and start the Adapter.
Sample project and other Coherence Adapter takeaways
I used Jdeveloper 12c release 18.104.22.168.0 to implement the example SOA composite. It contains a scenario which is similar to the one from the introduction, but with much less overhead. A simple service will take a userId as an input and provides the cached data (token and timestamp) as an output.
Since we have used the local cache here, you could re-use the schema in your other SOA composites, apply the same steps as listed above and share your cached data across multiple services. Keep in mind to always use unique ids!
This would cover a basic usage of the Oracle SOA Suite Coherence Adapter in 12c, as well as a workaround for the missing cache invalidation for local caches. Of course, you could experiment around the adapters functionalities. For example, you could use the query operation type or leverage an API to have full cache control – it’s all up to you. Stay healthy and happy coding!