Many SCN blogs are already out there (like this excellent one: DynamicAttributeChangeBean - The no-mapping solution to changing Dynamic Configuration ... dynamically!) explaining ways to set dynamic configuration attributes.
This blog adds another simple idea to enhance the flexibility of the bean.
- Take key and value as one set (rather than requiring key.x, value.x pattern)
- Iterate through all the module keys (skipping the top level "module.key") and obtain their values
- More importantly, provide ways to call a specific method within the module
I have created 3 methods within the bean and by suffixing the parameter name with keywords .HELP, .XPATH or .CONSTANT, I am able to call the corresponding specific method. Either new attributes are created or the existing ones get updated.
Parameter name ending with .HELP and value true shows the Help Text for this module. This can be used whenever the module usage is in question and the developer needs some help. (I sincerely wish SAP takes this idea and implements this in all their standard modules to display help, and saves a lot of googling (or binging) time of developers trying to find the available parameters/usage of a given module.)
Parameter name ending with .XPATH evaluates the given XPATH parameter value against the XML payload and dynamic attribute value.
The parameter name can be standard FileName or Directory (prefixed with the standard namespace), or an entirely new one (prefixed with any namespace) depending on the needs. (I usually use http://www.freeformatter.com/xpath-tester.html to validate my XPATH expression on the payload before setting it as the parameter value.)
The below screenshots show an example of setting up the target directory and file name values on a receiver file channel.
Parameter name ending with .CONSTANT will simply set the constant parameter value.
I enabled Add Counter as well
Please note that this blog is not to show how to set the file/directory names. It rather is to show the ability to branch out from the standard process method to call another method to set the value. If you get the idea, you know that your custom module's functionality can be extended as much as any Java program can be - Append, Replace with a value of another existing attribute (like the @ notation used by SEEBURGER), Timestamp etc..
While this gives a choice for the developers to create as many methods as they want, simply select a specific method and pass the expected arguments to that method, it also presents the challenge of balancing the act carefully. Customizing too much and later updating even a small part of it will force testing of all interfaces that the custom module is implemented for.
I used NWDS 7.3 SP16 EHP1 for development and PO 7.4 SP11 for testing. (If you would like to know how to create a custom module, refer to this nicely written detailed blog: How to create SAP PI adapter modules in EJB 3.0)
Here is the code.