I’m looking for a way to make audit property “include pipeline” as configurable via a configuration file.
I know the value of this property is present in the node.ndf file in the flow service folder under the IS machine.
I’d like to know how to make this file as configurable. Do you have any suggestions?
I don’t think swapping node file is a good idea.
If you are looking at an easy way to consistently turn on auditing info, you can create a new flow service template which have “Include Pipeline” turned on. Then when creating new services, you can just use this template instead of the default one.
you can create new template at:
Preference>Software AG>Service Development>Element Property Template
HTH,
There are four pipeline options: NO_PIPELINE, SAVE_PIPELINE, RESTORE_PIPELINE_NO_MERGE, RESTORE_PIPELINE_MERGE
Don’t forget to import:
com.wm.lang.ns.NSNode
com.wm.lang.ns.NSService
com.wm.app.b2b.server.ns.Namespace
I have a study to do. The goal is to determine if it is possible to make “include pipeline” property as configurable.
This would allow to set by default all audit pipeline properties to “On error only” and change this property to “always” if an analyse is needed.
Proposition 1:
We have a list of flow services requiring an audit property to “always” in a configuration file. The application roll-out set the “include Pipeline” property of these services to “always”.
Proposition 2:
I would like to set out the “include pipeline” property of my flow services in a configuration file in order to allow the production team to edit this property when they want to check the pipeline. The production team can use neither the developer/designer nor node.ndf files. That’s why the configuration file idea is proposed. This configuration file would be used via a UI and looks like that:
X*
X*
...
...
*where X can be set to 0 (never), 1 (on error only) or 2 (always).
I developed a Java Service allowing to change the “include Pipeline” property to “always” for a given service name.
However, I have a persistence issue. Indeed, the java service change the property in the code, BUT not in the node.ndf file. Consequently, when I reload the package, the property comes back to the previous value…
You are right, but at least it will serve as a workaround as upon the package load the value read from the node.ndf will be overridden with the value specified in your config.
There are some more properties for which such a feature can be of interest:
Caching enabled/disabled
Cache Expiration TimeOut
Retry Settings
…
Therefor I asked for submitting an idea on Brainstorm to see what SAG R&D is thinking about it.
Maybe we get a sustainable solution for this in one of the next releases when we all vote for this idea.
I added the service in start-up services and reloaded the packages. Finally, the result is the same : the value is modified in the code but not in the node.ndf file.
Adding the service for changing the values as a StartupService will not lead to effect that the new values will be persisted in the node.ndf.
It just makes sure, that upon every load (or reload) of the package the originally persisted values will be replaced in memory with those read from the config-file.
Additionally (as already stated in this thread by other authors) it is not really a good idea to manipulate the node.ndf-files manually. If there goes any thing wrong upon save the service will not be loaded upon next load of the package.