The following diagram and examples describe how geodata services are consumed:
In the diagram above, a replica exists between an enterprise geodatabase in New York and an enterprise geodatabase in Los Angeles. The replica was created by first publishing the Los Angeles geodatabase as a geodata service with the Replication operation allowed. An administrator in New York then accessed this geodata service over the Internet and used the ArcGIS tools to create a replica.
Once replicated, editors perform updates to each enterprise geodatabase locally. The administrator in New York periodically runs a geoprocessing model to connect to the geodata service in Los Angeles and synchronize changes in both directions. This keeps the geodatabases synchronized, allowing users to access the same information at either location.
There are also replicas between the Los Angeles enterprise geodatabase and local geodatabases running on field-workers' laptops. The field-workers disconnect from the network, make updates to their local geodatabases during the day, then synchronize with the Los Angeles database at the end of each day.
In this case, field-workers can use checkout replicas to file geodatabases. At the end of each day, the laptops are connected to the Los Angeles geodatabase, and changes are checked in. Once check-in completes, new checkouts need to be created for the next day's work. This can be done using a geoprocessing model that is scheduled to run overnight. To avoid having to run the checkout process each night, two-way replicas can be used instead of checkout replicas. A two-way replica allows multiple synchronizations, which can both send and receive changes. Therefore, at the end of the day, each laptop can run through a synchronization process to both upload changes and get the latest modifications from the Los Angeles geodatabase. Geodatabases in SQL Server Express running on each laptop can be used to create the two-way replicas.
These processes can be run locally in the office by plugging the field laptops into the LAN each night. In cases where field-workers are too remote to make it back to the office each night, they can also run the processes on the Internet. Here, instead of accessing the geodatabase directly, they connect to the geodata service published for the Los Angeles geodatabase over the Internet.
Once integrated, the changes from the field-workers are also shared with the New York office when the enterprise offices synchronize.
The SOAP URL for a web-enabled geodata service takes the following format:
For example, if you had a service Lima in the folder Peru running on a server gisserver with the port number 6080, the URL would look like this:
The REST URL follows the same pattern with /rest/ inserted between arcgis and services: