Skip to Content
Technical Articles
Author's profile photo Morten Wittrock

A closer look at the CamelContext

In my previous blog post, I listed some of the variables available in Apache Camel’s Simple expression language in Cloud Integration. I didn’t go into the details of the camelContext variable, though, because I felt it deserved a post of its own. This variable is a reference to an object implementing the CamelContext interface, which lets you access a ton of interesting runtime information.

In this blog post, 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 Cloud Integration 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 Cloud Integration.

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.

Assigned Tags

      2 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member

      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.

      Author's profile photo Morten Wittrock
      Morten Wittrock
      Blog Post Author

      Hi Brian

      Sorry for the late reply. I started out with the Simple language documentation, trying out the various built-in variables. Some work in CPI, others don’t. This changes over time as well, by the way ? The Camel version was one of the things I wanted to track using the CPITracker.

      Cheers,

      Morten