Using Launch Configurations to Run Services

In Designer, you create launch configurations to run services. A launch configuration contains the information Designer needs to execute a service. You can create one or more launch configurations for each service.

When running the service, Designer invokes the service (just as an ordinary IS client would) and receives its results. The service executes once, from beginning to end (or until an error condition forces it to stop) on the Integration Server on which the service resides.

Note:
You also create launch configurations to debug flow services. You can use a launch configuration created for running a service when you debug a flow service. Similarly, you can use a launch configuration that you created for debugging a flow service when you run a service. For more information about launch configurations for debugging flow services, see Creating Launch Configurations for Debugging Flow Services.

Designer requires launch configurations to run services. However, if a service does not have an associated launch configuration and you bypass the Run Configurations dialog boxes when running the service, Designer creates one on the fly and saves it in your workspace. You can use this configuration from one session to the next. In fact, Designer reuses this configuration every time you run or debug the service without creating another launch configuration.

By default, Designer saves launch configurations locally in an unexposed location in your workspace. However, you might want to share launch configurations with other developers. You can specify that Designer save a launch configuration to a shared file within your workspace; this location will be exposed. On the Common tab in the Run Configurations dialog box, select the Shared file option and provide a workspace location in which to save the file.

You might consider creating a launch configuration for each set of data that you routinely use to test your service. This will provide you with a ready-made set of test cases against which to verify the service when it is modified by you or other developers in the future. Many sites establish a workspace project directory just for holding sets of test data that they generate in this manner.