Guidelines for Refactoring Variables
You can refactor variable (field) names within Integration Server elements such as IS document types, flow services, Java services, specifications, and triggers. Refactoring variable names involves renaming the variable and then updating usages of the variable that occur elsewhere, such as in the pipeline, other flow services, or document types.
The following table identifies the IS elements in which variable names can be refactored by Designer automatically.
Element | What can be refactored? |
IS Document Types | Variable names in a document type. |
Flow services | Variable names in the signature. Variable names used for variable substitution in the following properties of flow steps:  Label property in all flow steps Scope property in all flow steps Switch property in the BRANCH step Input array and Output array properties in a LOOP step In a MAP step: Indices used in a link when mapping arrays Copy condition properties of linked variables Map set (assigned values and links) and map delete (dropped variables) Timeout property of the flow steps, BRANCH, CATCH, FINALLY, INVOKE, LOOP, MAP, REPEAT, SEQUENCE, and TRY Count and Repeat interval properties of REPEAT step Failure message, Failure name, Failure instance properties of the EXIT step |
Java services | Variable names in the signature. Note:
Refactor within Java code is not supported. |
Specifications | Variable names in the signature. |
Triggers | Variable names used in a local filter for a webMethods messaging trigger. The variable names used in a filter must be enclosed within %. If variable names are not enclosed in %, you must manually change the variable name. Note:
Provider filters cannot be refactored. You must manually change provider filters. |
In addition to the above list of IS elements in which a variable can be refactored, keep the following guidelines and limitations in mind:
To refactor variable names in an IS element, you must have write access to the element and its parent folder and have the element locked for edit (if locking is in use).
You must refactor a variable in the source element and not in dependent elements or locations.
You cannot perform a rollback of the changes after you refactor a variable.
Software AG recommends that you back up your packages before refactoring.
You cannot refactor local variables (variables added in the Pipeline tab using
).
You cannot refactor variable names in the pipeline.
Designer allows rename only in the pipeline. However, if you rename the variable here, you may create a broken reference.
If you refactor a variable in a publishable document type, you must resynchronize the publishable document type with its provider definition.
Any variable occurrence that cannot be refactored by
Designer must be refactored manually. That is, you need to find usages of the variable, update the variable name, and then change or redo the mapping of that occurrence (for a variable usage in the pipeline). Note that even after a manual update of a usage, the link that
Designer maintained to the original variable name is lost forever. Any future rename of the original variable require manual updates to the same occurrences that could not be refactored manually.
When you refactor variables,
Designer provides a preview of all the elements selected for refactoring except messaging triggers.
Designer refactors the usages even if the element is locked by another or the user doing the refactoring does not have Write access to the elements.
For flow services and IS document types,
Designer displays the
IS Asset Compare view which shows the changes between the original asset and the refactored asset.
When you refactor a variable that shares the same name and type with another variable, the preview lists both the variables. Carefully inspect the flow service to ensure that you select the right variable for refactoring.