In order to make the conversion from your design time environment to your runtime environment easier and to make your deployed project easier to maintain, it is a good practice to remove any hard coded references to files or external resources that may be used such as image files, XSL Style Sheets, and DTD or Schema files.  xCommerce provides a special DOM for this purpose in all projects called PROJECT.  You may have seen it in the pick lists for DOMs during the tutorial.  You add elements to the PROJECT DOM that you wish to be available across a whole project.  The PROJECT DOM has a global scope throughout the project and can be used in any component in the Project.

Set up Project Variables for any resources whose locations may be different between your design time test environment and your final production environment.  It is often more convenient for development and testing purposes to use local copies of DTD files or XSL files.  However, when you are ready to production test or deploy the final project and services you don't want to have to re-specify the final locations for all these files.  A good technique for centralizing such file specifications for easy modification between your design and production versions of a project is to use PROJECT variables.  PROJECT Variables also make a deployed project easier to maintain by only changing PROJECT variables values to change the behavior of a project.

Process:

Say you have an XSL file that is used by 5 components in a project.  You may create a Function action like the one below five times, once in each component.

Having five copies of the same specification is cumbersome and prone to errors if you make changes.  Instead you can create a single PROJECT Variable that points to the file on your local disk drive.  Access the Project Variables dialog tab from the Designer window menu choices: Tools | Configuration.

Then you can reference the PROJECT Variable in the five actions in each component.

Now if you need to change the location for this DTD for production testing or during routine project maintenance you can make your changes in this one place.

You can also use PROJECT Variables to turn on and off debugging statements in a project which can be very handy during development of a project.  First create a PROJECT Variable that will serve as your On/Off switch.

Then inside your components, wrap your debugging messages inside a Decision action...

During development of a project you can simply change the DebugSwitch to "On" and then run your components.  You can dynamically turn debugging On or Off by changing the value of DebugSwitch during component execution.  For instance, you may include in your Service's input document a DebugValue element.  The Service can then dynamically map this value to the PROJECT DOM before executing any of its components which read the variable to decide whether to write debug messages.

Note - although you can update the values of PROJECT variables from an Action Model, you can't save the new values (they return to the original value at the end of each Service execution).  You do NOT want to put variables such as sequence numbers here!