Stripping off the ECID Header using Oracle Traffic Director

My long-time followers will know that I like Oracle Traffic Director (OTD) a lot (and its Sun iPlanet heritage): it is a fast, stable and mature software load balancer.

OTD is available on Exalogic, with WebLogic Multi-Tenant, and more commonly now as a component of Oracle Java Cloud Service or SOA Suite Cloud Service.

Recently I was asked if OTD could strip the ECID HTTP header off inbound requests to SOA. Whilst I knew I could manipulate or remove headers, I hadn’t done that with ECID before… and it turns out that is not quite so straight-forward and there’s no documentation about it. Therefore last weekend I burnt quite a few midnight hours on this, along with one the Oracle Support OTD engineers in California, and we came up with a solution. Unfortunately, for non-technical reasons, this solution hasn’t gone into production but I’m confident it could, so thought I’d describe it here in case anyone else has the same requirment (I also suggested on the SR that a MOS note is written about it).

What is an ECID?

Firstly, let’s recap what an Execution Context Identifier (ECID) is. This is a unique ID, attached as the ECID-Context HTTP header, that is propagated through the various layers of an application stack to allow you to track and correlate requests. For example, if you are using SOA you can us Enterprise Manager (EM) Fusion Middleware Control (FMWC) to track all the steps and calls to other systems that a composite might make.

Typically a Fusion Middleware components will add a new ECID if one is not there, or pass it through, with or without manipulation if it is. OTD is a case in point – by default every request sent to an origin server will have an ECID, and if there wasn’t one on the inbound request OTD will generate one… this also alludes to the fact that the ECID-Context header is “special” for OTD.

What was the requirement?

This particular case involved an on-prem Oracle SOA platform calling our SOA CS platform repeatedly (1000s of times) as the source system processed a bulk feed. Transactions weren’t involved so every call to our SOA platform was essentially independent but, because the call already had an ECID corresponding to the instance on the source, this meant we had lots of instances with the same ECID, which in turn made EM FMWC unusable. So I was asked to remove the ECID, in that way either OTD or SOA (it didn’t matter which) would give each call a new, unique one.

I specifically needed to strip off the ECID for a particular service, not all services since that would impact composites and proxies that we did want to be able to trace. Therefore the global <ecid>false</ecid> option in server.xml was not an option (unless you choose the horrible workaround of having a separate OTD instance for the one service!).

Failed Attempts

My first attempt, and most obvious approach, was just to remove the ECID in <virtual-server>-obj.conf as I would for any other header:

<If $uri=~"/exampleuripattern">
NameTrans fn="set-variable" remove-headers="my-unwanted-header"

Note that when you reference a header in this way it must always be in lower case, even it the header itself is upper or mixed-case.

However that did nothing in the case of ECID-context – the directive was either ignored or, I think more likely, the ECID-context was not in the headers at the point the processing is taking place. I won’t go into the detail of my numerous other trials but they all either had no effect or else resulted in HTTP 500 errors.


The final solution, as proposed by the Oracle engineer, was this:

<If not $internal and $uri=~"/exampleuripattern">
<If $vars{'ecid'}>
AuthTrans fn="set-variable" remove-vars="ecid"

Note that the $internal test is to ensure this variable change is not made for OTD internal health-check calls (as they would fail), and you may prefer to condense the If into one statement.

So instead of trying to remove the header itself, you are telling OTD to behave differently on the fly for this one URI, and not output the ECID that it would have done. This worked perfectly – whilst it does mean you have a hard-coded reference to the service name in OTD, which I think is unavoidable, it is very precisely targetted and so doesn’t need a full regression test (which was also important on this project as the platform was already in production).

I hope this is useful to someone in future (I can’t help feeling it might be me!).

Further reading

For general information about OTD you can check out a presentation I did with Jacco Landlust here:


Presenting with Jacco at Oracle User Group Holland (OGh) in February 2016


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s