CustomWare Local Variable Holder coding style

, ,
1

Are there any standards or best practices to be following while developing Flow services?

We have already completed our dev. But we have lots of variables that are in the pipe line.
We also have some of the variables not dropped after they are used up.

Will that affect the performance? We still didn’t go live into production.

What are the problems that we face when we go live into production?

Is there any document that we can read to get the above details?

2

The GEAR documentation available from Advantage can help answer some of your questions.

Failure to cleanup the pipeline is a bad Flow programming practice for lots of reasons. Extra copies of large documents consume excessive memory, unintended consequences of having identically named variables, on and one. Best practice = drop all variables as soon as they are not being used. At least add a pub.flow:clearPipeline step at the end of your service to return only the variables you intended.

Mark

3

I have noticed that localVariable document pattern is very effective.

For people who don’t know about this pattern. Its simple, create a service specific temporary local document to hold all your variables created and used in that service. As the last step of the service map out all the out parameters and drop the complete document.

If any one need an example let me know I can cook one up very quickly or point you to the source of this pattern.

Ram Challuri

4

While I guess I could see some advantage in placing all of your working variables for a service inside a temporary document, you’re not really buying much over just maintaining good pipeline hygiene.

After all, the pipeline is just a document (IData). Creating another IData inside the pipeline to hold stuff you plan to discard later is not much different.

You still need to drop unused variables as soon as they are produced by an invoked service. Also, if large documents were placed into this local document you could not effectively drop one of them from your local doc once you were finished with it.

Maybe I’m missing something. Can you post a link to this “pattern”?

Mark

5

Mark,

Don’t get me wrong. This pattern is not replacing good pipeline hygiene. I strongly belive that “One has to drop variables when they deemed not required”. Instead this pattern only helps people to enforce the good pipeline hygiene by making it a requirement but easy to map the invoked service outputs to the local document and subsequently dropping every thing else. This will enforce 2 things.

  1. Don’t use the invoked service output variable. Always map them to your own variables.
  2. Always drop input and output variables when you think they are not required anymore.

The URL I was taking about is

[url]http://www.customware.com.au/repository/display/WMPATTERNS/Local+Variable+Holder[/url]

6

Ram,
What you mentioned is a very good point. But is this true in all cases:

Suppose that you have a child service being invoked multiple times which has the same inputs something like a pub.flow:debugLog and the logLevel being a constant. In such a case if you define the logLevel under a document, then it has to be explicitly mapped always. In case it lies int eh pipeline it gets implicitly mapped.

Also there are situations where in the pipeline at design time and the pipeline at run time will be different. In that case u cannot map those varibales under a document and the pipeline will still be unclean.

Also when u define all the varibales under asingle document then keeping hte scope for a sequence will become difficult.

The approach you have mentioned surely works out perfectly except for a few exceptions. I will try out your approach in my next code and will let you know

Thanks,
Pradeep

7

I liked with Ram’s way of handling pipeline variables/dropping technique wrapping up in a document and just drop it finally.Anyways else use clearPipeline (preserve wanted stuff used by down the path).

Quote:
“One has to drop variables when they deemed not required”

8

This coding practice was given a name and published by Rob and Nathan at CustomWare. Ram was just referencing their work in his post.

9

Pradeep,

I agree with you that there will be exceptions for not using this pattern. As I mentioned in the post its a pattern to be used just to be on the safe side. But if you are very keen about the performance and you are taking good care of how to achive it, you probably don’t need to use it in those exception senarios. In my short experience with webMethods coding and code reviews, I came across so many services with not even one drop variable nor clearPipeline statement. Enforcing localVariable pattern has solved the problem by large extent but as discussed there are exceptions.

Mark,
You are right, I am just trying referencing the work done by Rob and Nathan at CustomWare. I happen to talk to Rob on this issue and he pointed us to this pattern and ever since I have been implementing it.

Cheers,
Ram Challuri

10

I favor the usual webMethods (GEAR?) programming practise - use variables as normal, but drop them as soon as you don’t need them.

This is especially important under LOOPs - otherwise a value from one iteration may overwrite an empty value in the next iteration.

11

I’ve found local-variable-holder style programming (like the pattern that Customware have documented) necessary only once… this was for services that received arbitrary HTML form variables posted in. Since webMethods allows multiple variables to have the same name, there was the risk of user-posted variables colliding with internal variables and affecting control flow. To minimise this risk, I created a local holder variable and “indented” local variables under it. For eg:


_UniqueName
  - Allowed
  - ErrorMsg
  ... etc

To remove any user-variables named ‘_UniqueName’, I also used a simple Java service to remove specified variables from the pipeline (this is opposite to clearPipeline which preserves specified variables and clears the pipeline).



// pipeline
IDataCursor pipelineCursor = pipeline.getCursor();
	String[]	filter = IDataUtil.getStringArray( pipelineCursor, "filter" );
pipelineCursor.destroy();

if (filter == null) 
{
	throw new ServiceException("No variable names to filter out were passed in");
} else {
	for (int i = 0; i < filter.length; i++) {
		String filterMePlease = filter[i];
		while (pipelineCursor.first(filterMePlease)) {
			pipelineCursor.delete();
		}
	}
}
12

the packages imported in webMethods are same as the packages imported in java

13

the packages imported in webMethods are same as the packages imported in java

14

IMO, both the local-variable-holder approach and use of clearPipeline encourage lazy programming. Yes, the local-variable-holder allows a simple drop at one spot in the FLOW service, but IMO that just moves the clutter. I follow these principles (from GEAR and CustomWare): 1) drop variables as soon as possible; 2) drop only inputs/outputs when invoking services–use “cleanup” map steps when done with other vars; 3) use local-variable-holders/documents for scoping only when necessary (relatively rare); 4) use clearPipeline as a tool of last resort (e.g. when there is too much code to change to clean things up).

15

Hi reamon,

I have seen that use of clear pipeline under loops was effecting my processing. Infact it was a major bottle neck when it was used under loops. I discourage use of clearPipeline in my flow and use the best programmign practise as you have rightly mentioned "Drop the varibale as soon as it finishes its job "

Rgds,
Pradeep