Refactoring Variable Names in Elements
If you want to rename a variable in an element, you may need to refactor the variable instead of simply renaming. When you refactor a variable, Designer updates all the usages of that reference in flow services, including pipeline mapping, IS document types, or other elements.
Renaming without refactoring can result in broken or invalid references, which are sometimes called “ghost references”. The reference is broken or invalid because in places where the variable is subsequently used, such as mapping variables or assigning a value to a variable in the pipeline, Designer does not update the internal path that it maintains to the variable with the new variable name. Common situations where a broken variable reference occur are:
A variable in a service signature is renamed and that variable was already mapped to another variable in the pipeline for an INVOKE or MAP step. With only a rename, the variable may exist twice in the pipeline (once with the old name and once with the new name). Additionally, it’s possible that only the variable with the old name will retain the mapping.
A flow service uses a document reference in the input signature. In an INVOKE step within the flow, a variable in the document reference is mapped to a service input. A variable in the document type to which the document reference points is renamed. The renamed variable is the same variable that is mapped in the flow service. Because the variable in the document type was merely renamed, the INVOKE pipeline shows a variable with the old name and a variable with the new name. The variable with the old name retains the mapping to the invoked service. If the document type variable had been refactored, only the variable with the new name would appear in the pipeline and the mapping would be updated.
A value is assigned to a variable in the pipeline. The variable, which may be defined in a service signature, a document type reference, specification, etc., is renamed, but not refactored, in the original location. The pipeline view shows variables with the original name and the new name. The variable with the original name retains the assigned value. If the variable had been refactored, only the variable with the new name would exist and it would have the assigned value.
You add a variable to the pipeline, assign a value to it by linking it to another variable or using
to set a value, and then rename the variable. The pipeline will have the variable with the new name and the old name. The variable with the old name retains the mapping. Because the pipeline view does not allow refactoring, you must manually update any usages.
A variable is renamed and that variable is used in flow step properties, mapping, or in local filters for a
webMethods messaging trigger. Merely renaming the variable does not update the locations where the variable was used as part of variable substitution. When the variable is refactored,
Designer locates and updates variable substitution usages. Note that
Designer does not support refactoring of variable in the pipeline.
Changing the variable data type after the variable is used in pipeline mapping, variable substitution, or in local filters for a
webMethods messaging trigger.
Example of a Broken Reference
Following is a simplified example of how renaming a variable can introduce a broken reference.
1. The flow service input signature contains two String variables named abc and def. The output signature contains a String variable named alphabet.
2. The flow service invokes the pub.string:concat. The String variables abc and def are mapped to inString1 and inString2, respectively.
3. In the Input/Output tab of the flow service, the input variable abc is renamed to a. Rename is accomplished by right-clicking the variable and entering a new name.
In the pipeline for the invocation of pub.string:concat, notice that under Pipeline In, there are three variables: abc (old variable name), a (new variable name), and def (unchanged input). The variable abc retains the mapping to the pub.string:concat input inString1. Variable abc now is a broken reference and the mapping is invalid.
In comparison, if the abc variable had been refactored, a broken reference would not have been introduced.
1. Refactor the variable by right clicking the variable and selecting Refactor > Rename, Designer prompts you to rename the variable and then displays all the usages that need to be refactored to reflect the new name.
2. After you click Finish, Designer refactors the usage of variable abc, displaying a log when it is done.
3. When viewing the pipeline for the INVOKE step, you can see that the renamed variable a exists and is mapped to inString1 as abc used to be.
