Hello,
We are checking for sleuth like functionality in webMethods SOAP and REST APIs which can help us in tracing of the transaction through out multiple systems. Is there any in-built feature like Spring Sleuth is available in webMethods which can help achieving that ?
We are using Product: webMethods Integration Server and Product Version
is 10.5
Hi @Mitulsinh.Mahida
In general, distributed tracing can be accomplished by having a unique ID/string that is sent across to each system involved in the overall request flow. This unique string would be logged in all the systems.
The answer for this would therefore need to consider the different systems the request flows through. Please provide some more details about the flow.
There are some solutions which can be built using custom HTTP header for tracing , but would need to know more information to proceed.
-NP
Thanks for the reply Nagendra.
I am looking for some built-in functionality that can help to trace the end-to-end flow of requests passing through multiple systems like Frontend(Angular) to ESB webMethods and ESB webMethods to Java microservice.
@Mitulsinh.Mahida , can you be more specific? I am asking because Spring Sleuth (and other frameworks, even for totally different purposes) provides a certain set of capabilities. These capabilities can be used in very(!) different ways. That makes it difficult to answer your question in a helpful way. Because, strictly speaking, the only software that provides capabilities like Spring Sleuth is, by definition, Spring Sleuth. So in that sense the only possible answer is no. However, this does not help you much, does it 
But if we talk about what your business and later(!) technical requirements are, we can map those requirements against what webMethods provides.
I know that webMethods is used at various global customers where distributed tracking across a plethora of systems around the globe has been implemented. So it is definitely possible to achieve this. What exact approach makes sense for you can only be determined with more details on the requirements, though.
Not sure if that is what you wanted to hear. But in my experience it is helpful to first look at the requirements, at least up to a certain level of detail. Once that is understood, diving into the technical details will provide a much better, and almost always also cleaner/simpler approach.
Hope that helps.
Agreed with @jahntech.cj ,
@Mitulsinh.Mahida as far as I understand, Spring Sleuth requires the different systems to be spring applications, and use common indicators , such as the trace id and the span id to group related logs.
You need to figure out if distributed tracing is what you are looking for and what exactly you need to accomplish. A beginning to end use case , with what you would need to do with the correlated data might help with your case.
-NP
Thanks for the response Nagendra and Christoph Jan.
We are looking for request tracing throughout the transaction which passes through multiple systems like Frontend to ESB webMethods and Java microservice.
Each trace includes these three key pieces of information:
So, If the call to ESB webMethods calls another microservice then the trace headers will continue in the called service as well.
So we are looking for some built-in features that can help to achieve this without writing a custom logic.
Is there any built-in feature available that can do this commonly for all SOAP and REST calls and act as an interceptor?
I understand that we can achieve this through custom logic but I am looking for the built-in features related to that if any.
You basically need to ensure that the relevant IDs are handed over between service invocations.
As to the wish of having something out-of-the-box (OOTB), I can understand where you are coming from. However, in my experience this is a dangerous route to follow. I am pretty certain that this is not what you want to hear. But please let me explain my view.
I have been working in the integration space since 2001 and in all those years I have not had single client whose requirements were the same or very similar to another on a detailed technical level. Of course, conceptually the requirement is almost always what you wrote. (So you are in good company here .) But as soon as you dig a bit deeper the differences come up.
A trivial one is the length of the UUIDs. There are legacy systems that are limited to e.g. 16 characters. So you cannot use a standard Java UUID as an example. In other cases the trace ID and the span ID are encoded into a single string and need special handling in various sub-systems. The list goes on …
The biggest risk with an OOTB solution is that it may fit your current needs, but not a future one. So in my view it is much safer to have a “custom” approach. This does not have to be super fancy. In fact, passing a couple of IDs through with every request comes at almost no cost in terms of development effort. Because you pass through the actual payload (e.g. order details) already. So adding an additional structure does not requirement much work. In fact, in most systems I have seen such an additional structure already exists. Because you have things like technical routing information that go with the business payload.
I am not against using OOTB solutions. On the contrary! But this is one area where I make an exception. And if management has reservations, because they assume that it is much additional work, my experience is actual the other way around. But I guess that is a separate discussion …
Thanks for the insights Christoph Jahn
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.