Hi,

I’m using wm 6.1 and I have a question about the contextID.
In fact, I have a service which uses the following Java lines:

String context = InvokeState.getCurrentState().getAuditRuntime().getContextStack();
String rootContextId = context[0];

The generated rootContextId is non-repetitive when I run this service several time. But sometimes, I encounter an important problem because this service gives me the same rootContextId, but the value of rootContextId should be non repetitive.

Do you know how the rootContextID is generated? Is it possible that the rootcontextID has several times the same value for different runs?

Can you give me any advise please?
Thank you.

“…but the value of rootContextId should be non repetitive.”

I think you may have made an erroneous assumption.

Yes, it is possible for the rootContextID to be the same over multiple runs. A document published via the Broker will have a context ID. When that document is processed by an IS subscriber, the root context is not generated by IS but is extracted from the document. Thus, each trigger/trigger service invoked by a single publish (multiple subscribers) will have the same root context ID.

OK. I give you the context.
I have a service which is a start service, this means that it is called just one time at the start of a flow. This service uses the 2 previous JAVA lines to generate the rootContextId, which is an identifier for this flow.
This service is called for every new flow. So, this identifer has (and must have) a different value for each new flow.

The problem I encounter is that sometimes flows have the same rootContextId. :mad:
This is probably due to the “start service”, and to be more accurate due to the 2 JAVA lines which allow me to generate this flowID.
Today, I would like to understand the cause of the problem and if possible solve it. But I don’t know how to…

Thanks.

How is that initial “start service” invoked? Via an HTTP post? FTP put? Scheduled task? Via a subscription trigger?

The 2 lines of Java code do not generate the rootContextId. They retrieve an ID that has already been created by IS.

OK. Thanks for your response Rob.
I better understand now the mecanisme of generation of the rootcontextId. I had a doubt but know I’m sure: this ID is generated by IS.

In fact, I have a webservice which is invoked by a soap request. This is the start of the flow. This webservice uses the initial “start service” for retrieving the flowID.

So if a problem occurs with the flowID (for two different soap requests, so two webservice invocation, so two different “startservice” calls), it means that the IS encounters a problem to generate the ID.:o

Tell me if you don’t understand or disagree.
According to you, Rob, in that case, is it an IS problem or is it due to the code?

Thanks for your responses.

Excellent question. I’m not entirely sure when the root context ID is created. Is it during the creation of the session? At the start of the top-level service? I don’t know but I’m interested in finding out!

It certainly isn’t due to your Java code, but it may not be an IS “problem” either–we just need to understand the behavior.

Are the two service calls made during the same user session?

If you want a unique identifier, and want to separate your services from the behavior of the IS root context ID generation (maybe a good idea), then you might use com.wm.util.text.UUID.generate().

Julien,
Did you try retrieving the ParentContextId of your service?
Also, Enable Service audit logging on your WebService. Then you should cross check the ContextId(This is what you need) of this WebService in Monitor against the Id you are retrieving in your start service.
IS may maintain three IDs for a service at any state. RootContextId, ParentContextId and ContextId.
I think what you are looking for is the ContextId of your webservice which may be the ParentContextId of your start service.
Also, is your start service a Java service or is it calling a Java service with the code you mentioned?

Good questions sekay. That leads to another question: what is the root need that Julien is attempting to use the context IDs for? Perhaps there is another approach that would not rely on the unknown/unspecified behavior of the IS managed context IDs.

Yes, Rob. I totally agree with you.

Julien,
I think the only reason you may want the contextId is when you want to tie something(like your error handler) back to Monitor, or to do your own custom logging that ties back to Monitor.

If that’s not your requirement, as Rob mentioned -you should take the approach of UUID.generate(), instead of relying on the core IS internal functionality of contextIDs.

Sekay, reamon,

thanks for your responses and ideas.
I’m still encountering my problem. I haven’t yet resolved my problems.
I don’t think method to generate the contextId is the cause.
I think there are some parameters like stateless or calling http parameters like keep-alive… or I don’t know what!

The problem doesn’t happen at every call of Toplevel service (I have difficulties to reproduce it).
Do you have other ideas to investigate further?

Thanks in advance.

I work with Julien O. And I would like to bring some precisions :

• the problem occurs on soap-rpc calls.
• we have checked the stateless parameter on the called service (wmroot.server.soap.rpc). It is set to true.
• we have tried to call our service on a loop by setting the http header parameter Connection to Keep-Alive.

This problem occurs on at least three interfaces. The common thing between theese two interfaces is the protocole soap-rpc.

Thanks in advance to all.

Since we still don’t know what you’re trying to use the root context ID for (no new information) my advice is as before:

“If you want a unique identifier, and want to separate your services from the behavior of the IS root context ID generation (maybe a good idea), then you might use com.wm.util.text.UUID.generate().”

This issue keeps being referred to as a “problem” but since 1) the root context ID isn’t intended for user consumption; 2) how/when it is generated and controlled isn’t documented for us–we have no idea if this is a problem or not. It may be performing perfectly to spec. But since we don’t know what that spec is, I’d advise not using it since it is not functioning in a way that you desire.