Studio best practices

Some guidance for using Studio to its full potential.

Establish naming conventions for your organization
Provide unique, meaningful names (meaningful in the context of the business problem being solved) for all your Studio projects and related components—files, folders, projects, orchestrations, endpoints, and so on. Names should be:
  • Unique - Studio is case sensitive: filename1, FILENAME1, and FileName1 are three different files. However, do not rely on capitalization to distinguish among Studio projects, it can lead to confusion.
  • Descriptive - For example, a project that integrates suppliers and an inventory system might be called “SupplyChainIntegration.”
Back up projects frequently
In multi-user environments especially, be sure to back up projects frequently. You can quickly back up all Studio project components by simply creating a compressed file of the contents in a specific project's directory. Store the compressed file elsewhere, in a secure location. Ideally, in a version control system that will let you also track project changes.
Store projects in a central location
Place all project files in a central location, preferably using version control software, so that projects are easy to find and previous iterations are easy to recover (this is especially important if you have numerous developers working on the same project).
Design orchestrations for optimal performance
When possible, preprocess as much input data using the native facilities of the source systems before integrating. Transforming data outside the source system adds to the processing overhead. If performance becomes an issue, investigate how you can minimize the use of the Map Activity in an integration project's orchestration.
For example, if you are integrating data from several different database systems, consider creating extract tables that preprocess the data, rather than trying to resolve all differences among disparate data types in the orchestration.
Use Configuration Properties for endpoint definitions
Rather than hard-coding details in your project endpoints, you can use properties for some of the details. You define these configuration properties in Studio and then use the Management Console to specify various runtime values. Before deploying the project, you must configure the properties for the actual endpoints in the production environment. For more details, see the online help.
Test activities and all definitions in Studio, as you design
As you use Studio to design all the elements of an orchestration, be sure to use test data wherever appropriate to ensure that mappings work as expected. Before publishing a project, test all mappings and flat-file schemas using Studio.
Set up development and test environments
Ideally, you should set up development and testing environments that mirror your production environment, including replicating data sources and targets in the test environment.
  • Extract (or replicate) production data to your development and test environments.

Before deploying the project, you must configure the properties for the actual endpoints in the production environment by changing the Configuration Properties. See the Management Console online help for details.




Feedback | Notices


Timestamp icon Last updated: Tuesday, 27 September 2016


http://pic.dhe.ibm.com/infocenter/wci/v7r0m0/topic/com.ibm.wci.gettingstarted.doc/getstart_studiobestpractices.html