I have a couple questions regarding organizing projects and orchestrations, both from a Studio and a WMC perspective.
I'm working on an SFDC integration. We have a number of orchestrations for each object we've integrated. Initially, I've created separate CI projects for each object, so a project will contain only the orchestrations relevant to that object. So right now, I have 6 projects, each specific to an object and containing a small number of orchestrations (2 - 8). However, there is also much in common with each of the projects (endpoints, wsdls, custom functions, some configuration properites).
One big drawback to the way I've organized this is that you can only open one project in Studio. So if I need to make the same change across multiple projects, I have to do each one separate and have to do it manually (can I copy/paste between projects?). Therefore, I've been thinking about combining all the orchestrations into a single CI project.
Overall, what are issues/implications with a large number of projects containing a small number of orchestrations vs. a small number of projects containing a large number of orchestrations? Is there any impact one way or another for the WMC and runtime? Is there performance overhead having a large number of projects each containing a small number of orchestrations?
Any insights/experiences/best practices regarding organizing proejcts and orchestrations, from a Studio and from an appliance perspective, would be greatly appreciated.
NOTICE: developerWorks Community will be offline May 29-30, 2015 while we upgrade to the latest version of IBM Connections. For more information, read our upgrade FAQ.
This topic has been locked.
1 reply Latest Post - 2013-01-07T09:26:12Z by SystemAdmin
Pinned topic project/orchestration organization
Answered question This question has been answered.
Unanswered question This question has not been answered yet.
Updated on 2013-01-07T09:26:12Z at 2013-01-07T09:26:12Z by SystemAdmin
SystemAdmin 110000D4XK100 PostsACCEPTED ANSWER
Re: project/orchestration organization2013-01-07T09:26:12Z in response to SystemAdminHi Mark,
I know this post is now 3 years old and your problem might have been solved meanwhile, but I want to provide an answer for others who might have the same problem.
Your design seemed to be reasonable. It is possible to copy orchestrations using Cast Iron UI with a right-click on the orchestration and select copy. Open the other project and select paste.
As an alternative, the files stored in the project folder under orchestrations or endpoints can be copied. Remember to save your projects in Cast Iron before copying to make the changes take effect.
Regarding general project/orchestration design, there are several aspects to take into account:
- Reuse of certain parts in other orchestrations - do copy and paste or use common projects (e.g. common error handler)
- Availability: If all orchestrations are contained in one project, a new version requires a project to be stopped.
- If a project is stopped, all orchestrations are stopped. Therefore orchestrations contained in one project should be related.
- I am not aware of any performance restrictions that have an effect on orchestration design.
For further information please check chapter 3.3, 3.4, and 6.1.3 Cast Iron redbook