Clarify supports a minimum of two types of server environments: the Local Test Server and remote Server(s).
Remote Servers can provide test and/or multiple production environments. No matter how many environments, each has its own purpose and should be utilized according to that purpose.
This topic offers some general guidelines and best practices for both server types.
- Business Processes with parameters cannot be launched, as there is no mechanism for manually entering a value for parameters. In order to launch a Business Process with a parameter, you must encapsulate parameters in another Business Process that assigns them value.
- File Monitors, Database Monitors, Email Receive Monitors, Web Services, and Harmony Monitors are started/stopped from Admin Console / Resource Monitors.
- The results of executed processes can be viewed in Admin Console / Auditor.
- The Server Log view displays log information for a selected server, supporting all server types, including Server Cluster environments.
- Active Projects in your Workspace are available for deployment once a server starts.
- Admin Console / Projects displays a list of all objects deployed on the server. It also displays deployment errors, which can be very useful when troubleshooting issues on the Local Test Server.
Note: Avoid hard-stopping servers.
- Don’t start the Local Test Server immediately after starting the Studio. Instead, only start it when ready to test an integration process.
- Ensure that the Local Test Server isn’t started while converting objects from previous versions.
- Ensure that the Local Test Server isn’t started when checking out objects from an SVN Repository.
- Global Variables will be updated in the Local Test Server when modified in the Studio.
- Always close Projects that contain invalid objects, or objects that aren’t ready for development testing, before starting the Local Test Server. Valid objects automatically deploy, but will be unusable if referenced objects are not valid. An example is a Business Process that references a Ruleset with a reference to an invalid Schema.
- Run the Local Test Server in debug mode to assist with troubleshooting integration projects.
- If you experience deployment problems or are missing expected objects, use the Project | Clean option from the main menu to rebuild the Project’s objects.
Once satisfied with the results of local testing, always commit your Project to an SVN Repository and then deploy it to a remote test Server.
- One person is assigned the role of deploying test or production Projects. This ensures that the intended Project (with the correct objects) is deployed, and avoids deployment of duplicate Projects from different Workspaces.
- Ensure the Server is started prior to deployment.
- When deploying a Project with a large amount of Packages and/or objects, the initial deployment process may take longer than normal.
- Servers should be backed-up at regular intervals.
- If you need to change a Global Variable, Next Number, or Control Number Generator value, you must do so in the Settings View. Updating the value in the Studio and re-deploying the object has no effect.
- Disable the communication paths to your trading partners. Instead, use the file system to test your solution’s output.
- Ensure that all objects are saved in your SVN Repository, or in a different branch for test data.
A production Server is installed on a different machine than the Studio. Once you complete testing on the test Server, deploy the Project(s) to the production Server where your production data processes.
- Ensure that communications to your trading partners are enabled.
- Ensure that all objects are saved in your SVN Repository, or in a different branch for production data.