- This topic has 4 replies, 1 voice, and was last updated 9 years, 2 months ago by
.
-
Posts
-
-
Hi.
I recently took a BizTalk course, and our instructor mentioned that we might want to organize all BizTalk maps in one BizTalk project, all orchestrations in another BizTalk project, etc.
Is this good practice? What is the logic behind organizing things this way? Wouldn’t it become quite unmanageable at some point? Maybe I missed the point of what he was suggesting–it might make sense if you had to create a huge project with multiple maps, multiple orchestrations, but otherwise, I just am not seeing it.
Thanks!!
QT -
Hi! What you heard from your instructor about seperating different BizTalk \”pieces\” into seperate projects is good practice. What I usually do is I have 1 solution, lets call it SampleSolution. Underneath this solution, I have 1 project for each piece in the solution…so orchestrations get a project, transforms get a project, pipelines get a project and etc. I usually name my projects with the solution name followed by a period and whatever component happens to be. So for my SampleSolution, my orchestrations project would be called SampleSolutions.Orchestrations, my maps would be called SampleSolution.Transforms and so on.
This tends to help keep things organized and a bit less chaotic. It also is handy if you use custom deployment tools such as the Deployment Framework from Scott Colestock. Hope this helps!
-
-
Just to add a little more to this post, I am winding down a project where we organinzed the solution by functionality. For example, we created a new project for each action (createItem, updateItem, confirmupdate, etc…). Each project had its own orchestration and transform map. All projects shared common schemas and pipelines, which were implemented as separate projects. Thus, our structure was as follows:
SampleSolution
SampleSolution.CreateItem
SampleSolution.UpdateItem
SampleSoluiton.ConfirmUpdate
…
SampleSolution.Pipelines
SampleSolution.Schemas
SampleSolution.ComponentThe rational for this solution structure was that we felt it would be easier to maintain if an action needed to be updated in the future. We would only need to replace the single assembly containing that action.
During development, we quickly discovered that each time we had to tweak a schema or pipeline, we had to undeploy each and every action assembly before we could deploy the update. This quickly became a rather tedious task. The Deployment Framework can simplify this task considerably, but you will need to make modifications for each solution you create if you use the approach I am describing. If you use the suggestion made by the instructor, however, you can use the Deployment Framework, essentially wothout modification.
In hindsight, my next project, I will structure my solution into BizTalk pieces, as mentioned, because I now realize the maintenance will essentially be the same, but deployment will be much simpler and less complex. (you still only need to redeploy a single assembly.
I hope this helps.
JimM
-
-
-
-
- The forum ‘BizTalk 2004 – BizTalk 2010’ is closed to new topics and replies.