Macros
Macros can be created and the values defined within any macro set, including Global and Local. A macro name can be duplicated in any number of macro sets when you need to use the same macro in a map, process or data profile but the value of that macro changes per customer or some other criteria. When the same macro name is defined in multiple macro sets, which value gets used during execution is determined through the macro precedence. See Below.
Macro Precedence
You can have macros with the same name as long as they are defined in different macro sets. In this case, the precedence order is as follows:
1. GLOBAL
2. Workspace-level/non-global macros (as per their order number)
3. LOCAL
You cannot reorder GLOBAL and LOCAL macro sets but you can reorder non-global macro sets, within a project or configuration. By reordering you can change the precedence. For example, if you have three customers, all with the same map that writes to a database. You can define one macro (for example DATABASE) in three different macro sets. When writing for customer-1, you can move MacroSet-1 to the top and use "MySQLdb". When writing for customer-2, you can move MacroSet-2 to the top and use "OracleDB", and so on.
Note: You should never use local macros during design-time. Local macros are only applicable at runtime and they are automatically setup when execute action is called. If you need a local macro at runtime, you must set up a regular or global macro at design-time, test with that, then add those macros to local, assign an override value, run, save and move them to production.
Note: You can use encrypted macros and GLOBAL macros for sensitive values such as passwords to prevent them from being viewed in plain text. The macro names for encrypted macros are also read-only. If you want to change the name of an encrypted macro, you must delete it and then recreate it with the new name.
Topics:
Last modified date: 10/22/2024