none
Is Biztalk the right tool? Tight time frame, lack of resource etc RRS feed

  • Question

  • We have a requirement to interface a cloud based source system to an onsite destination system with flexibility in mind to include further onsite destination systems later down the line.

    • A master list of Suppliers is held in the cloud
    • Each supplier in the cloud is a flat data structure with lots of metadata/fields
    • When a supplier is added the cloud system will notify us by a web service call All fields will be sent along with the primary/unique id's.
    • When a supplier is updated the cloud system will notify us by web service call. The updated fields will be sent along with some primary/unique id's to identify the supplier.

    Part of the data held against a supplier indicates which internal companies the supplier trades with. This data will indicate which destination system the data should flow into as each company (for now) has a unique ERP system! To start with the short term goal is for us to implement only one of these destination systems but this logic is still applicable. I do however in implementation want to have the other implementations later down the line in mind.

    Because the initial ERP system is vastly more complex compared to the flat structure of the source system there is a considerable amount of logic which has to take place. The integration into the initial ERP will be accomplished using web services. However various will need to be called depending on what situation presents itself. i.e. depending on what fields are updated and sent will change what action has to take place. We were thinking of making it scenario based. i.e. Id this field = that and this field = that then we need to do this! which internally may have lots of look-ups/translations in itself. i.e. codes sent from source don't mean the same thing in the destination. The flexibility has to be there so this logic cannot be deeply integrated into code preferably allowing non developers to amend/add/change scenarios should there be a need. We were also thinking there would be a catch all scenario which would simply log/email in order to capture updates which are falling through to later identify future scenarios.

    There is unfortunately no field to field map here, maybe some fields are but alot are not i.e. if a field = yes in the source then it may mean two accounts have to exist in the destination meaning two web services calls to insert some information which has to be first queried. I hope I've explained the complexity enough.

    Either way, I have to decide between rolling our own interface/logic/workflow vs using Biztalk or similar. Money is tight and so is time. 3 months ish with 1 contractor in mind and some support from myself.

    Opinion? Thanks.


    Tuesday, June 12, 2012 9:24 AM

Answers

  • Applications are a way to seperate BizTalk artefacts into logical groups. They make it easier to develop, deploy and administer a server. But there is nothing to stop you from putting everything into 1 big application. You can use scripts to work around some of the difficulties this might cause.

    The main differences between Standard/Enterprise are "high volume, reliability, and availability". If you are going to need to scale out beyond one server with 2 processors you will need Enterprise

    see http://www.microsoft.com/biztalk/en/us/editions.aspx

    BizTalk sounds like a potential candidate for your problem, but it doesn't sound like you have the budget for it really. If it's to be the foundation of a long term integration strategy and replace your existing point to point integrations over time then go for it. But you talk about reducing development budget and using it for BizTalk licenses. Where are you going to find a single BizTalk developer to work for 2-3 months under these conditions and timeframe? How will you judge if they are any good? Maybe you want to learn BizTalk yourself and apply it to your current integrations, in this case a pilot project using Developer Edition might be the best approach.

    Tuesday, June 12, 2012 11:32 AM

All replies

  • IMO the transformation capabilities and pub/sub architecture of BizTalk can help you here. But if money is the concern and you don't need the scalability and reliability provided by BizTalk then you can also look for AppFabric for Windows. But both of these options have the learning curve.


    Please mark the post answered your question as answer, and mark other helpful posts as helpful, it'll help other users who are visiting your thread for the similar problem, Regards -Rohit Sharma (http://rohitt-sharma.blogspot.com/)

    Tuesday, June 12, 2012 10:01 AM
    Moderator
  • Firstly, appreciate the response!

    Money is a concern but there is a small budget which was for a contract developer for 2/3 months! If a technology exists which can help cut the need for the developer then the budget is transferable. We are trying to do this with future integration in mind too! We have many point to point integration's managed by SSIS/DTS/Scripts etc and would love to get a better solution for delivering system integration's!

    What is the cost of Biztalk in simple terms? Difference between standard and enterprise looks to be Applications allowed? How do you explain Applications/what is the best deployment method? I guess being introduced as a strategy standard would cause an issue! Can standard be upgraded to enterprise easy enough later if more and more integration's come on board? Final question :) is one server license enough too? I know its has scalability/reliability etc but I assume all this comes with the expense of having numerous servers running biztalk!?

    Tuesday, June 12, 2012 10:47 AM
  • Applications are a way to seperate BizTalk artefacts into logical groups. They make it easier to develop, deploy and administer a server. But there is nothing to stop you from putting everything into 1 big application. You can use scripts to work around some of the difficulties this might cause.

    The main differences between Standard/Enterprise are "high volume, reliability, and availability". If you are going to need to scale out beyond one server with 2 processors you will need Enterprise

    see http://www.microsoft.com/biztalk/en/us/editions.aspx

    BizTalk sounds like a potential candidate for your problem, but it doesn't sound like you have the budget for it really. If it's to be the foundation of a long term integration strategy and replace your existing point to point integrations over time then go for it. But you talk about reducing development budget and using it for BizTalk licenses. Where are you going to find a single BizTalk developer to work for 2-3 months under these conditions and timeframe? How will you judge if they are any good? Maybe you want to learn BizTalk yourself and apply it to your current integrations, in this case a pilot project using Developer Edition might be the best approach.

    Tuesday, June 12, 2012 11:32 AM