View source | Discuss this page | Page history | Printable version   
Main Page
Upload file
What links here
Recent changes

PDF Books
Add page
Show collection (0 pages)
Collections help


Understanding Import Entry Replication

Bulbgraph.png   Starting from RR16Q4 below functionality is available

The Import Entry framework is used for many different functionalities, i.e. to support high volume import, ensured distribution of changes, sending messages from one server to another etc.

When working with import entry records it is important to understand that these records are replicated automatically between store and central server. This is defined in the Retail Storeserver Synchronization module.

Import Entry Replication and Double Processing

When you create a new import entry record in the store server then it will be replicated to the central server. However, the 'import state' property is not replication between servers. So when replicating to the central server the import entry record will be created (in the central server) with status 'Initial'. The same applies to the other direction.

As the import entry starts with status initial on the other server it will again be processed there.

This is something to take into account. This can be perfectly fine and intentional (to replicate and process on both servers).

However, if the replication definition includes the tables which are updated/filled with the import entry processing code then you should in general not replicate the related import entry types. This is for example the case for the standard retail transactional tables like order and cashup related tables. Even the business partner tables are replicated. So in the OB Commerce Retail Storeserver Synchronization we prevent replication of the import entries for these retail transactional types.

Preventing Import Entry Replication

To prevent replication programmatically, you can use the following api-call:


As import entries are created through java it is the easiest approach to add this prevent-replication logic to an eventhandler. OB provides a default eventhandler which you can extend.

Here is some example code on how to do this:

public class RetailImportEntryNoSyncEventHandler extends ImportEntryNoSyncEventHandler {
  // the types of import entries in this list are only to be executed in the current server
  // and not synced.
  private static final HashSet<String> IMPORT_ENTRY_TYPES_TO_NOT_SYNC = new HashSet<String>(
      "BusinessPartner", "BusinessPartnerLocation", "OBPOS_App_Cashup", "FIN_Finacc_Transaction",
      "OBPOS_RejectQuotation", "OBPOS_VoidLayaway"));
  protected boolean isPreventSyncForTypeOfData(String typeOfData) {
    return IMPORT_ENTRY_TYPES_TO_NOT_SYNC.contains(typeOfData);

So with these api you have full control on the intended replication and re-processing on the other server.

Retrieved from ""

This page has been accessed 846 times. This page was last modified on 25 November 2016, at 17:23. Content is available under Creative Commons Attribution-ShareAlike 2.5 Spain License.