• Receives and parses XML messages from 

  Companyname

  , either directly or from the remote proxy   
• Processes the messages, usually by accessing external system (XS) data
• Frames an XML response and passes it back to 

  Companyname

  .

The 

Note: one major advantage to developing the ESA in Java is that it can easily be linked with the bundled 

An addition is necessary for HTTPs ESA's, which can initiate calls beginning a sync to the 

ESA Properties

To be synchronized with 

• It must be possible to obtain the modification timestamps for each record. This timestamp is typically contained in the record itself, but this is not absolutely necessary.
• Record IDs should not be changed, or at least there must be a way to determine any record ID as it was in the last sync. Record IDs can be remapped during sync, but the old ID must be made known to the ESA in order to track record matches. 
• Records from the external system, as presented during sync by the ESA, must be grouped by structures, which are mapped on a 1-to-1 basis to 

  Companyname

   types or tables, such as People/Employee. An ESA structure can be a table, a folder, a file or anything else that logically groups records in the external system. Within a given structure, external records must use the same set of field mappings.

Choosing an ESA Deployment Type

The following guidelines can help when designing your ESA deployment:

• If your external system is a server or a continually running daemon-like process, implementing the ESA as a module of the system might be a better option, since you can control the life cycle of the ESA. In this case, the ESA should connect with 

  Companyname

   over HTTPS. 
• For an application that is not always running, use the command-line form. 
• If you need to trigger synchronization based upon external system events, use an HTTPS and possibly daemon-like ESA. A command-line ESA cannot connect to 

  Companyname

   on its own, and will only be triggered with 

  Companyname

   begins a synchronization. 
• If you don't need the external system to ever trigger a synchronization, develop your ESA as a command-line application, using standard I/O communication with the XS. If the ESA is not on the  

  Companyname

   host, an ESA Remote Proxy will be needed for it to interface with 

  Companyname

  , but the ESA will be simpler to develop. 
• The 

  Companyname

   ESA for QuickBooks must run on the 

  Companyname

   host, but otherwise ESAs can fit into any of the above contexts. Firewall configurations will often determine the most convenient deployments, which will in turn dictate certain sync configuration options. 
• Once an ESA has been designed, it can communicate with systems of the same type, not just with a single server. For instance, once an Exchange ESA is written, you may set up synchronizations with many Exchange servers, not just with that particular Exchange installation. 
• Java classes for message handling are available for any ESA that is to be developed in Java. The ESA Interface Reference topic describes the extensive reusable Java classes available, and provides a complete ESA in Java. 
• Communications use the XML-RPC model, where XML messages are sent to and from the 

  Companyname

   server.  However, when an ESA is remote, the communication flow is actually reversed in order to allow communication through firewalls. The remote ESA actively polls for the next XML-RPC message on the 

  Companyname

   server. Logically though, the communication is the same because the ESA only performs commands issued by the sync subsystem and is therefore passive. This polling is handled by the Java support libraries provided by 

  Companyname

   and need only be considered if you are developing an ESA using a programming language other than Java. 

Calls To and From an ESA

All communications between 

• Calls - Method Calls
• Results - including exceptions

Most calls come from Sync to the ESA, but the ESA can respond by a call to the 

A remote Command-line ESA can never initiate a syncn cycle, but an HTTPs one can do so, by a call on the 

Call ID

Every call has a mandatory call-id attribute. This attribute should be set by the caller to a positive integer value. It is recommended but not obligatory that this value would be incremented on each call. A result of a call has a "response-to" attribute, filled by the call-id value of the call, to which this result belongs. This simple mechanism allows monitoring of message flow and detection of communication or application failures.

ESA Data Model

• Every record must have a unique numeric or string ID
• Every record must have a modification timestamp

The ESA must provide the 

Responsibilities of ESA Components

There is a clear separation of responsibilities between the 

• The 

  Companyname

   sync subsystem manages the generic synchronization logic: 
  • initiating synchronizations
  • comparing records in both systems
  • deciding which records on which systems are to be updated
  • resolving conflicts after an update, and so on.
• The ESA manages the Create/Retrieve/Update/Delete operations on the external system. 

An ESA always communicates with the external system and never accesses 

ESA Parameters

An ESA usually requires some initialization parameters in order to do the synchronization, such as external system name, port, schema name, and so on. For the most part, synchronizations are quite simple and it would place an unnecessary burden on the 

• The ESA provides the 

  Companyname

   sync subsystem with a list of parameters it needs, including parameter names and types. Several simple types are supported, such as string inputs, choice fields and so on. 
• The 

  Companyname

   administrator sets up the sync configuration through an 

  Companyname

   GUI that allows the admin to map these parameters to 

  Companyname

   tables so that synchronization can take place. 
• At run time, the ESA obtains these stored parameter values, using the parameter name as the key. 

This mechanism provides a simple way to manage configuration and synchronization data. Your ESA may or may not use this facility. It is not mandatory, but it is recommended to make the configuration easier for the 

Sync Configuration

Before running a synchronization, the 

• The name of the ESA to be synchronized with
• The type of external system and ESA parameters. Usually this includes the server to synchronize with, but some ESAs such as Facebook do not require this information.
• Table and field mappings between the systems. 
• A number of other parameters, such as one- or two-way synchronization, conflict resolution settings, polling and so on. 

When the configuration is complete, the synchronization is ready to run. Every sync configuration has a unique ID, called the external system ID, which is a handle used to identify the configuration when communicating with the ESA. the external system ID is automatically generated by 

Pseudocode

Pseudocode for an ESA is: 

Boolean quit = false;
Do
{
  String xmlMsg = readXmlMessageFromEw();
  Message parsedMsg = parseXmlMessage(xmlMsg);
  // Dispatch message
  Message result;
  Switch (parsedMsg.type)
  {
    Case getModified:
    {
      // Find all modified records ...
      result = new RecordListResultMessaqe( modified records);
      break;
    }...
    Case update:
    {
      // Update a record
      result = new RecordResultMessaqe( updated record);
      break;
    }
    ...Case release:
    {
      // Release all resources...
      quit = true;
    }
    Default:
    {
      result = new ExceptionResult("Unkno wn operation");
    }
  }
  String xmlResponse = xmlizeResponse(result);
  sendResponseToEw(xmlResponse);
} While (Not quit)