If there is an interesting requirement where our client have offices that are located in different locations. The Internet connection is not that stable between the head office and all this offices and they want 100% availability of the system.
At the same time they want to work the whole system together so that one person on location1 will do something and head office guy will get the data instantly and work on it.
Now to solve the high availability problem, one solution could be having separate AX system running in different offices. But the question comes how then the synchronization will happen with the head office?
Is this possible to use multiple Ax systems in hub and spoke manner.
Actually it depends on full scenario
In one case where there is HQ and multiple site business all site businesses itself qualified as separate ERPs so individual ERPs are running on Site and consolidation data and all the bulk transactions get uploaded in the system. If you want details in this let me know I will elaborate further
2) If on sites the transactions are typically only sales, purchase or GL related
1 ERP in head office, and localized solution on Branches and it will replicate batches to HQ as soon as connection is established
The replication and sync. in this case is very straight forward only a localized solution needed in this regard
3)ERP at head office, implement AX Retail on Branches and add extra things as new customizations, Sync. of these happen as connection is restored.
the customer must set realistic expectations, as an unstable connection will definitely mean that the data is not always synchronized.
A possible alternative to using an Internet connection would be a leased line, but that also means higher costs. 100% availability could mean that they perform a transaction on a branch even when the line is down, and that branch has local inventory, but they will have to wait until the line is up to sync the data.
There are one of two solutions for this case Internet high availability or synchronization and maintenance headache. I have the same case in my current company and we are working with the first solution and provided high availability Internet access with remote desktop licenses and that's all.
There might be some alternatives where you will be having some difficulties in each of them. But in any case, if you want the Head Office guy to be aware of all the transactions entered by the other locations users, there must be a fast connection between the different locations. The following suggestions are in case you wanted to deploy the system with two instances and with two databases as mentioned above:
1. To have a transitional replication on SQL Server databases. Here is a post about Microsoft support for the Dynamics AX database replication.
http://blogs.msdn.com/b/emeadaxsupport/archive/2011/02/15/database-replication-with-ax-2009.aspx
2. To have the integration through the data Export/Import utility in AX2009 and AX2012 with that generates binary files (dat and def). You might export the data for example by the end of each day from the locations, and import them in the HO database. You need to do some aggressive testing in here to insure that you covered all the tables needed.
3. To have a consolidated company where it consolidates the transactions in the Head Office DB, this consolidation is done at the financial data only, so it is a limited solution. I don’t think this is useful in your case.
The hub and spoke model is not supported in AX. Once you deploy/install an instance for AX, then all components are installed in that instance.. you cannot separate those components.
what i think, Transactional replication is not good approach. As many complexities are involved in it when you try it with Dynamics ax. The problems which you will face would be like 1st of all number sequence problem, in case both ax have auto generated number sequences. even if you resolve this number sequence by keeping it manual in one ax instance. what about the major issue the Transactional replication can crash at any time. and if it crashes, it would be a disaster for both ax installations because Technically Transactional Replication creates a similar table in System B, as that is in System A, when 1st time setup is done
At the same time they want to work the whole system together so that one person on location1 will do something and head office guy will get the data instantly and work on it.
Now to solve the high availability problem, one solution could be having separate AX system running in different offices. But the question comes how then the synchronization will happen with the head office?
Is this possible to use multiple Ax systems in hub and spoke manner.
Actually it depends on full scenario
In one case where there is HQ and multiple site business all site businesses itself qualified as separate ERPs so individual ERPs are running on Site and consolidation data and all the bulk transactions get uploaded in the system. If you want details in this let me know I will elaborate further
2) If on sites the transactions are typically only sales, purchase or GL related
1 ERP in head office, and localized solution on Branches and it will replicate batches to HQ as soon as connection is established
The replication and sync. in this case is very straight forward only a localized solution needed in this regard
3)ERP at head office, implement AX Retail on Branches and add extra things as new customizations, Sync. of these happen as connection is restored.
the customer must set realistic expectations, as an unstable connection will definitely mean that the data is not always synchronized.
A possible alternative to using an Internet connection would be a leased line, but that also means higher costs. 100% availability could mean that they perform a transaction on a branch even when the line is down, and that branch has local inventory, but they will have to wait until the line is up to sync the data.
There are one of two solutions for this case Internet high availability or synchronization and maintenance headache. I have the same case in my current company and we are working with the first solution and provided high availability Internet access with remote desktop licenses and that's all.
There might be some alternatives where you will be having some difficulties in each of them. But in any case, if you want the Head Office guy to be aware of all the transactions entered by the other locations users, there must be a fast connection between the different locations. The following suggestions are in case you wanted to deploy the system with two instances and with two databases as mentioned above:
1. To have a transitional replication on SQL Server databases. Here is a post about Microsoft support for the Dynamics AX database replication.
http://blogs.msdn.com/b/emeadaxsupport/archive/2011/02/15/database-replication-with-ax-2009.aspx
2. To have the integration through the data Export/Import utility in AX2009 and AX2012 with that generates binary files (dat and def). You might export the data for example by the end of each day from the locations, and import them in the HO database. You need to do some aggressive testing in here to insure that you covered all the tables needed.
3. To have a consolidated company where it consolidates the transactions in the Head Office DB, this consolidation is done at the financial data only, so it is a limited solution. I don’t think this is useful in your case.
The hub and spoke model is not supported in AX. Once you deploy/install an instance for AX, then all components are installed in that instance.. you cannot separate those components.
what i think, Transactional replication is not good approach. As many complexities are involved in it when you try it with Dynamics ax. The problems which you will face would be like 1st of all number sequence problem, in case both ax have auto generated number sequences. even if you resolve this number sequence by keeping it manual in one ax instance. what about the major issue the Transactional replication can crash at any time. and if it crashes, it would be a disaster for both ax installations because Technically Transactional Replication creates a similar table in System B, as that is in System A, when 1st time setup is done