Skip to Content

In my previous blog post, I listed some of the variables available in Apache Camel’s Simple expression language in HCI. I left out camelContext, though, because I felt it deserved a post of its own. This variable is a reference to an object implementing the CamelContext interface. The CamelContext contains the Camel objects, that are generated by HCI based on your integration flow, and the interface provides access to those objects and other runtime information.

In this blog I will do a bit of exploring around the CamelContext. So, where to start? First off, let’s find out which class implements the interface:

${camelContext.getClass.getName}

It turns out the implementing class is org.apache.camel.blueprint.BlueprintCamelContext. Interesting, but what else can we learn? I’d like to know the version number of the underlying Apache Camel framework, and the getVersion() method returns just that. Let’s try it out:

${camelContext.getVersion}

At the time of writing, the method returns 2.16.2-sap-16, which indicates that this is an SAP variation on the Camel 2.16.2 release. However, just a few days ago, the version number was 2.16.2-sap-15. This is cloud software, after all, and as such, it is updated continuously behind the scenes.

Incidentally, the version number also explains why some features of the Simple expression language are not available in HCI at the moment, like for instance the messageHistory variable and the starts with operator: They were introduced in later versions of Camel (2.17 and 2.17.1, respectively).

Browsing through the API documentation of the CamelContext interface, another method looks promising: getUptime(). Let’s give it a go:

${camelContext.getUptime}

Shortly after deploying, the expression evaluated to 39.147 seconds. After making a nice cup of tea, it now evaluates to 7 minutes. The getUptime() method returns the human readable uptime of the context, i.e. the time that has passed since the integration flow was deployed.

The getUuidGenerator() method also looks interesting. According to the API documentation, it returns an object implementing the UuidGenerator interface. This interface has a single method, generateUuid(), which, to no one’s surprise, generates a UUID. Let’s try to do that now:

${camelContext.getUuidGenerator.generateUuid}

Lo and behold, the expression evaluates to a UUID, that is identical in structure to the message and exchange IDs in HCI.

Ok, I’ll briefly talk about one more method, and then I will leave you to continue exploring on your own: getStatus(). This method returns a ServiceStatus enum, indicating the state of the CamelContext (starting, started, stopping etc). Let’s check my current status:

${camelContext.getStatus}

The expression evaluates to Started, which sounds about right to me.

Okay, that’s it for now. Have you discovered other cool stuff, that can be done with the camelContext variable? Feel free to share it in the comments below.

To report this post you need to login first.

2 Comments

You must be Logged on to comment or reply to a post.

  1. Brian Michael

    Morten

    Love the post.  First question: How did you find camelContext was exposed?  and what others are exposed as well?

    I have been doing my own research, trying to push the limits using whats available in the ScriptContext – I have only been able to get “exchange” additionally.  

    Additionally, I have attempted to use simple from within a groovyScript. Although I can import the simple routine, no variables appear to be exposed from within the script.

    (1) 

Leave a Reply