I’m using the WmRoot Svc - wm.server.query:getAllServiceStats. The same service that is invoked in stats-services.dsp. The output from this service is provided in an document list/array structure which I can then loop over and retrieve various stats per service. But here’s the kicker - the SvcStats/SvcStats[0]/name element is returned in all CAPS eg. ACCEL.CONFIG:INITACCELCONFIG. And when I’m trying to use that element to invoke another svc (eg. wm.server.ns.dependency:getDependent) it naturally fails, because it can’t find it. The .dsp page correctly shows our services as they appear the package navigator eg. [Accel.config:initAccelConfig] and when I independently invoke the getDependent svc using the correct format, all is well.
So my question is am I able to do this conversion somehow in my flow? Is there another root or pub svc that can mimic that?
I suspect the webpage .dsp is calling some class or js function but I’m not able to understand how that’s being done. I just want to replicate that functionality or alternatively, have the output of the SvcStats/SvcStats[0]/name return the native/correct package/folder/service format.
Review the .dsp in more detail after the %invoke wm.server.query:getServiceStats% you’ll see that the code is using the ifc and svc objects for display, not name.
I’m unable to determine how the dsp is referring to ifc and svc in a way that makes them render a string. But the classname is shown in Designer. You may be able to use Java to get the string representation of those objects.
The question is how can I use these objects to format my packageName/seviceName correctly?
It’s not obvious to me how this is being accomplished in the JS file - “webMethods.js”.
This is where using a Java service may help. The ifc and svc are not being saved presumably because the com.wm.util.Name class is not serializable. In a Java service, see if you can cast the returned ifc and svc objects to the com.wm.util.Name class, and use methods to get the appropriate string from there.
I too am completely baffled by how the dsp is able to refer to ifc and svc and get the appropriate strings for display. In dsp it can be seen that there is a URL parameter webMethods-wM-AdminUI defined. I tried settng that in the pipeline where wm.server.query:getServiceStats would have access to it to see if that made a difference. It did not. There may be some other “magic” var involved that is signalling the service to return something other than the com.wm.util.Name object.
You can create a support ticket and ask them if there is a pub alternative and if there isn’t, how it works. They will tell you the functionality might change in the future etc. but they usually tell you how, if you ask properly (and nicely).
Hey Theo, Genius! Not entirely sure how you made those connections but that’s exactly what I was looking for. Prior to this, I had resorted to screen scraping the entire service usage html page into a csv file then some manual editing before copy/pasting that as an input to a service where I then had to convert my stringList into a DocumentList. Such a pain in the a*s!
Your solution was clean & easy. Hopefully others will benefit too if there’s a need.
No worries, Mick. I’ve been working with webMethods since version 1.0.2, so I know a bit about the internals. Extra tip for anyone looking for tips on using WmRoot services: There are quite a few Java classes that display as either strings (which is where objectToString comes in) or documents in Designer but, in reality, are neither. One major example is the Node object, which looks like a document, but requires conversion to IData (using the getAsData method) in order to map the data.
Cheers!
objectToString (or custom Java service) to get the string representation of ifc and svc makes sense.
What is still a head scratcher is how the DSP is getting a string when using the Administrator UI when the DSP is not referencing anything but the ifc and svc vars from the root service. Any thoughts on how that is working?
The %value% tag in a DSP or output template triggers a call to the underlying object’s toString() method to get the value. I confirmed this using a custom class that overrides the toString() method.
When Designer doesn’t recognize the class, it simply displays the class name.
I’m still confused. The behavior of com.wm.util.Name.is the default behavior for any object to does not explicitly override toString(), hence the class name being shown in Designer.
What is doing the “right” toString() for com.wm.util.Name for the DSP value tag?
Actually, the Object.toString() method returns the hashcode of the object as well as the class name:
public String toString() {
return getClass().getName()+“@”+Integer.toHexString(hashCode());
}
I don’t have access to Designer source code to confirm, but based on observed behavior, here is my (99% certain) theory. Designer doesn’t call the toString() method to get the value of an object. It “understands” how to decode/extract values from core Java classes and most of the underlying webMethods classes (Data, Values, Node, NSName (which replaced com.wm.util.Name many years ago), etc).
When it doesn’t know how to parse the data, it essentially does a getClass().getName(). In the case of my custom class, for example, Designer shows the value as Sandbox$Thing, while the %value% tag in the DSP returns the result of the toString() method of the class.
Testing with a java.lang.Object in the pipeline, Designer displays a String with the class name, while my DSP shows java.lang.Object@22625ab0.
