Is there anywhere in webMethods documentation that explains how to use the SCOPE input to a service.
I am trying to improve the performance of some code without converting it to Java (for policital reasons as always). GEAR says to use scope to limit what gets passed to a called service. However, neither GEAR, nor the Developer Guide properly explains how it is used i.e. How do you reference a document? Can you have more than one document in the scope? if so, how? Can you have a part of a document in the scope ie. document\field?
I read the following post with interest:
wMUsers Discussion Forums � Integration Server & Trading Networks � Flow and Java services � Archive through June 26, 2003 � Scope of the Service Cache
I was able to convert a lot of my service calls to transforms which automatically limited the scope. This has resulted in a a significant performance improvement. However, transforms have the limitation that, you cannot have an input document (or field in an input document) transforming back to itself). As an example, I have a service that takes as input and output a java list (amongst other things). When used as a transformer, the output is not mapped and the orginal value remains. This service works fine as a straight INVOKE. This means that I still have cases where I need to use scope.
I would be grateful if someone could provide me with help on scoping or, better still, using transformers as in the example above.
I missed this one before I posted:
wMUsers Discussion Forums � Integration Server & Trading Networks � Flow and Java services � Archive through June 02, 2004 � Archive through February 3, 2003 � Invoke Service Vs Use as Transformer
It basically confirms that, while transforms are good and vastly improved in wM6, I don’t want to be using for complex service calls. This is more reason to work out how to use SCOPE properly! ;o)
Use the name of the document in the scope field of the service you are calling.
On entry to the called service, the document “shell” is stripped away, and everything it contained is presented as the service input to the called service. Noting else in the caller’s pipeline is visible in the called ser vice.
So if you have a document named myDoc, and it has one string field named myString. If you set the scope of the called service to myDoc, when you enter the called service it will have only myString in its pipeline.
A quick question on your comments regarding the map step:
Is there much overhead for creating this map step for creating the scope document or is the mapping done by reference? The reason is ask is that I want to know when it is best to use this approach and when it is best to just leave it with the whole pipeline.
My initial thoughts are that, if the service to be invoked takes more than, say, half of the pipeline as input, the cost of creating the scope document may be greater than the savings made by using scope in the first place.
There’s a nice description of what happens on page 212 of the 6.1 Developer User’s Guide:
"What Happens When webMethods Integration Server Executes a Link Between
Variables at Run Time?
When executing a link between variables at run time, the Integration Server does one of the following:
Copies the value from the source variable to the target variable. For example, when you link a source String variable to a target String variable, webMethods Integration Server copies the value of the source String to the target String. This is called “copying by value.�
Creates a reference to the source variable and uses the reference as the value of the target variable. For example, when executing a link between a source document and a target document, webMethods Integration Server creates a reference to the source document value and uses the reference as the value of the target document. This is called “copying by reference.�
The Integration Server copies by value when the source or target variable is a String. (An exception to this behavior is that when executing a link from a String to an Object, the Integration Server copies by reference.)
When executing links between all other types of variables, the Integration Server copies by reference. Copying by reference significantly reduces the memory and time required for executing a link at run time.
When a value is copied by reference, any changes you make to the value of the source variable in subsequent flow steps affect the target variable. This is because the value of the source variable is the value of the target variable. The target variable does not contain a copy of the source variable value. If, in a later flow step, you used the Set Value modifier to assign a value to the source variable, you would be changing the value of the target variable as well. (The target variable references the value of the source variable.)"
Anthony wrote:
“As an example, I have a service that takes as input and output a java list (amongst other things). When used as a transformer, the output is not mapped and the orginal value remains.”
Are you explicitly mapping the output of the transformer? If not, that’s probably the issue.
Mark, I guess that the copy by reference and the fact that transformers run in their own threads is the reason why some of my services do not work as transformers. But now that I can work scope this should not be a problem.
Rob, yes I do explicitly map. For a service that takes a field in a document (d1\f1) the map step look like this:
d1\f1 ------- transformer --------- d1\f1
This does not work for me. However, as I said to Mark, I now have the means to get around this.