Whether you’re moving a data management job from your design client to a remote server or promoting your job from a development environment to a test or production environment, it will have to accommodate the differing environment settings and constraints found on each. Here we will explore some of the places where you will have to make design decisions to ensure your data management process works as expected wherever it might run. Many of these examples refer to functionality specific to the SAS Data Management Platform but are equally valid in concept, regardless of the data management technology you may choose to use.
Macros in the Data Management Platform are variables that can be set at design time, at run time or programmatically as needed. Macros make it possible to replace values with new values that need to change based on where a process is running or who is running it. Use macros to support portability in the following areas:
Removing data connection information from data management processes improves portability by allowing someone to update data connection settings without editing the data job itself. Here’s how to keep data access and data transformation logic separate.
Jobs have access to a number of system global values that can be used to execute job logic differently in disparate environments. Key off these values in your Data Management job expression code or node properties to alter the way the job behaves, depending on where it’s running or who started the process. Here are some of the more commonly used system global values:
Because different computing environments can have widely varying resources available to them, where possible, design your jobs in such a way that you can scale to take advantage of additional memory or processors/cores. Consider using this flexibility in the following areas:
Removing hard-coded username and password information from your data jobs is always a best practice. Ensuring security should be on the top of your list, especially when sensitive data is being accessed. A few things to keep in mind:
Windows and UNIX operating systems deal with filenames and directories differently. While Windows can be more forgiving (usually no problems handling both forward slashes and backslashes, for example), it’s best to design your code to handle filenames and file paths appropriately for the system where the job is expected to run. Remember to:
While we often think of localization when we reflect on the need to show the appropriate language for end users in web applications, localized values must be supported in job logic too. Consider the following:
There you have it – a brief guide to designing data management processes to run successfully across any number of related but divergent environments. Are there others areas not discussed here where your project was sidetracked because you didn’t plan for portability?