Search code examples
endecaendeca-workbench

Merge two Endeca Servers (Endeca 3.1) into one. Including their current data

Let me explain in more detail:

1st: I'm running endeca 3.1, so Endeca Server here refers to 3.0's Data Domain.

I'm required to use an Endeca Server currently present on Endeca (Downloaded a Demo VM). All the info on it, including, groups, attributes and data, must be merged into out Endeca Server. (It can also be the other way around, i could merge my Endeca Server into this one.)

So far, i've tried to do the following:

1) Clone the Endeca Server

2) use the putCollection sconfig operation to create a collection on it with the same name i have on mine.

3) Load configurations using the LoadCollection & LoadAttributes graphs from OEID POC Template 3.1. I point to the new collection on the Configuration.xls file.

This is where i encounter an issue. The LoadAttributes graph gets a T/O message from the server's WS. Then the config WSDL becomes inaccesible for a while. I can't go beyond this point.

I've been able to load data into the collection, but i need to load the attributes first.

THanks in advance for your replies.

Regards

Solution

  • There are a few techniques.

    Have you tried exporting the data domain and then importing it? You can use the endeca-cmd tools to export to a file, and then import from that file. This would enable you to add 2 datastores into one server.

    If you want to combine 2 datastores then that is a different question.
    The simplest approach in 3.1 if the data collections are small. Extract then as CSV (via a data-table), convert to XLS and add them via self provisioning into separate collections within a single data store. If you are running in the VM this is potentially the easiest approach.

    This can also be done using Integrator.
    You don't need to load the attributes unless you are using multi-value types. You can call against the conversation web-service to extract data and then load it using 'bulk-load' I would not worry too much about creating the attributes unless this becomes essential due to their type or complexity. If you cannot call against the conversation web-service, then again extract as csv and load using Integrator.