This section provides considerations in planning synchronization service and synchronization proxy topology.

Deployment overview

You must deploy the following components for Microsoft Project Server 2007 integration:

  • The synchronization service. This is a Windows service component that uses the Windows Communication Foundation (WCF) and .NET Business Connector to integrate with the Microsoft Dynamics AX application.

  • Synchronization queues. These are the Microsoft Message Queuing (MSMQ) queues used by the synchronization service. By default, these queues are installed on the same server where you install the synchronization service. You can install the MSMQ queues on separate servers for scalability.

  • The synchronization proxy. This is a .NET component that is installed on the Project Server host. The synchronization proxy requires application queues to be installed on MSMQ. The application queues can be installed on the same server where you installed the synchronization proxy or on a separate server.

Scalability and availability considerations in deploying the synchronization service and synchronization proxy

Consider the following when planning your synchronization service and synchronization proxy topology:

  • Windows Communication Foundation (WCF) for the synchronization service is configured by default in a per-call instantiation mode. In this configuration, WCF creates a new instance of the service class to process every request from the client. Therefore, the synchronization service does not hold any session state. This per-call instantiation can impact the throughput of the service. However, Microsoft Dynamics AX 2009 implements object pooling for the service class in order to maintain a high request processing throughput.

  • A dictionary of AX client sessions by the company is cached in each WCF service instance mentioned in the preceding step. The service retrieves the AX session for the company it needs to connect to in Microsoft Dynamics AX from the dictionary. If the key entry does not exist, it will create a new AX session and save the session in the dictionary after use for other threads to use.

  • To prevent lost updates, the synchronization service uses an API to check out a project on the project server, processes necessary updates, and then checks the project in. If the project it is trying to synchronize is checked out by another user, the synchronization service will abort the synchronization process and send a standard synchronization error message to the synchronization administrator. The synchronization service compares the RecVersion field of the main table of the simple entity being updated with the RecVersion of the entity in the synchronization service. If these two versions are different, the synchronization service will abort the process and send an error notification to the synchronization administrator.

  • The synchronization service takes advantage of the reliable messaging of WCF to guarantee that messages are read from queues once and only once. This reliable messaging is achieved by sending a message to the queue in a transaction so that the message is only placed in the queue if all the actions in the transaction scope are processed without any errors. Similarly, the synchronization service also reads messages from the queue in a transaction.

  • The Microsoft Dynamics AX application and Project Server do not support distributed transactions. Therefore, when a transaction requires updates to both the Microsoft Dynamics AX application and Project Server, the synchronization service:

    • Preserves the transactions in the synchronization store (a special table in the Microsoft Dynamics AX database) and provides capabilities to retry processing the transactions again if the previous processing fails.

    • Implements create, update, unlink, and deleteactions to be idempotent. Idempotency allows these actions to be implemented in such a way that even if the actions are performed more than once on an entity instance, the system will still treat it as one action. For example, a createaction on a project will only create one project even if the createaction is processed twice for that particular transaction.

  • The synchronization service is a WCF service and supports both scaling up and scaling out. This is discussed in the topology section below.

Topology considerations

When planning your topology, you need to carefully consider the workload and response time impact of integrating Project Server with Microsoft Dynamics AX. This section describes the synchronization service topology. The following diagram depicts a single-server topology and a small-scale deployment topology with two-server and three-server deployment options.

Single server deployment

You can install Project Server, the Synchronization Service, and the Application Object Server (AOS) on a single server in a development or test environment.

Important Important

This is not a supported scenario for a production environment.

Small-scale deployment

You can consider one of the following topologies for a small-scale deployment.

  • A two-server configuration includes:

    • Project Server on a dedicated server with synchronization proxy.

    • The AOS and the synchronization service, including the synchronization queues on MSMQ, on a dedicated server.

  • A three-server configuration includes:

    • Project Server on a dedicated server with synchronization proxy.

    • Synchronization service on a dedicated server (including the synchronization queues on MSMQ).

    • The AOS on a dedicated server.

Large-scale deployment

The synchronization service is a WCF service and supports the scale-up and scale-out models as follows:

  • Scale-up: WCF automatically handles scale-up. You only need to deploy one instance of the synchronization service on a server. WCF will use as many threads as it requires reading messages from the queues sent from its clients, either Project Server or the Microsoft Dynamics AX application.

  • Scale-out: You can deploy the synchronization service on several servers, with each instance processing requests from the client. You can scale-out the synchronization service in two different ways as follows:

    Configuration

    Scenario one: synchronization service and MSMQ deployed on the same server within a Windows Network Load Balancing cluster.

    Scenario two: synchronization service deployed on multiple servers and MSMQ deployed on a dedicated server.

    Clustering mechanism

    Windows Network Load Balancing (NLB).

    None. Synchronization service pulls messages from the application queue.

    Location of the synchronization queues (MSMQ)

    Both the synchronization service and the synchronization queues are stored on the same server.

    The synchronization queues are stored on a separate server. The synchronization service is deployed on multiple servers and is configured to pull messages from the application queue. The synchronization proxy is configured to send messages to the application queue.

    Model

    This is a push model where messages received from the client are redirected (pushed) by NLB to the synchronization queues.

    This is a pull model where the synchronization service on the machines pull from the same queue.

    Considerations

    In certain scenarios, NLB could potentially push the message to the same server as the previous request and not the machine with fewer messages to process in its queue.

    This role is only supported on Windows Vista. It is not supported by Windows Server 2003. This is because transacted reads from a remote queue in WCF are only available on the new version of MSMQ that is available with Windows Vista.

The following diagram depicts the topology for scenario one from the preceding table where both synchronization service and MSMQ are deployed together on servers that are configured in a Windows NLB cluster.

The following diagram depicts the topology for scenario two from the preceding table where the synchronization service is deployed on multiple servers and MSMQ is deployed on a dedicated server.