Is this possible with ArcGIS using replication?

Question

I work for a telecom company dealing with fiber management.

We have a sister company south of us who we share some fiber and fiber equipment with.

Both of us will be using ArcSDE databases.

We want to be able to share this area with each other, but we don't want to share our entire system. We want to be able to make changes in this area where we share fiber/equipment and sync the changes back and forth, but only for these areas.

Please see this image to have a visual:

We only want to sync changes made in the red area.

The problem I'm having with using something such as the two-way replica is that if I save the replica into the database where the data currently exists it doesn't merge with the current data, it creates new data with an _1, like instead of appending to the points feature class it makes a new one called points_1. This is a problem because it also does it for the geometric network which is being used by our fiber management software to track the fiber.

Is there anyway to get the replicated data into our original data and still only be able to sync that data?

I'm not sure if this made sense. It's kind of hard to explain.

Answer 1

It will not be simple to manage but it can be done.

Please note that the network (or objects) will need to be broken at the edge of the boundary or the overlapping objects will be included in both dbs.

A replica is created "from" an mxd document.
So queries, and versions are honored.
You don't describe the database and that will be key to the level of difficulty in the full time management.

You would need to study closely the esri managing replicas help
Also in-depth help is in the managing distributed data help
You need to decide what database will be used in the distributed data. This needs to be decided by the type of workflow you desire.
With file gdbs there is only a one-way distribution allowed.
So each time the edits are made. and accepted back to the parent, a new child must be distributed.

In my opinion this would make your management about a 10 on the order of difficulty.

An rdbms distribution makes this somewhat better but you have to manage schema and any changes very closely, otherwise the replica becomes broken and you have to stop editing (at both ends) to get resolution and restore workflow.

Using RDBMS replicas you can send packets both ways on a scheduled basis and keep each other up to date.

The other option would be a live connection between the two dbs but you only want to do that if you are both inside the same domain.

You mention a vpn but it is not necessary. depending on the amount of edits. You will essentially send just the deltas in a packet file back and forth.
The main gotcha in replicas is the schema changes.
Any change to a field, (name or other), domain (additions), tables dropped or renamed requires a tedious process. (there are tools for it though).
At this point I would get a sign-off from stakeholders that participating features, tables, and database objects will be unchanged in the schema.
Then either create the second rdbms using the parent or verify the schema are in fact the same between two differing dbs.
Then move to test phase and send the initial sync back and forth. (this will be time consuming the first time).
Then make small known changes in both dbs to send in a delta sync and crosscheck each db.
No this is using ONLY esri tools "USING RDBMS replicas" simply means that you can use two-way model sending changes from both dbs. Sorry I didn't read the geometric network line.
you would need to manage dropping and restoring the network before and after sync.