GeodatabaseSyncTask Creates Two Replicas in ArcGIS Enterprise

603
8
11-10-2023 06:52 AM
JoeHershman
MVP Regular Contributor

I have a tool for taking data offline which uses the GeodatabaseSyncTask

var gdbSyncTask = await GeodatabaseSyncTask.CreateAsync(serviceItem.ServiceUrl);

string replicaPath = $"{ConfigurationSettings.OutputFolder}\\{serviceItem.Title}.geodatabase";

var envelope = Geometry.FromJson(ConfigurationSettings.FullExtent)?.Extent;
var parameters = await gdbSyncTask.CreateDefaultGenerateGeodatabaseParametersAsync(envelope);
parameters.UtilityNetworkSyncMode = UtilityNetworkSyncMode.None;

job = gdbSyncTask.GenerateGeodatabase(parameters, replicaPath);

await job.GetResultAsync();

What I notice is that when I look at ArcGIS Enterprise at the /replica (https://serverName.domain.loc/server/rest/services/Mobilelayers/OfflineNetwork/FeatureServer/replica... endpoint on the feature service there are two replicas created 

JoeHershman_0-1699627692504.png

When I look at the .geodatabase generated it seems that the file always points to the second one.  I am using branch versioning for the first time, is this expected behavior with branch versioned data?  With standard archive data only a single replica was ever created (same tool, different ArcGIS Enterprise)  

 

Thanks,
-Joe
0 Kudos
8 Replies
JenniferNery
Esri Regular Contributor

I used your code to generate geodatabase from a feature service portal item but I only see 1 replica created. We also have branch versioning enabled on this feature service. What ArcGIS Enterprise version are you using? I tried ArcGIS Enterprise 11.0, utility network version 6. ArcGIS Runtime WPF build 200.2. 

JenniferNery_0-1699996232767.png

 

0 Kudos
TonyWakim
Esri Contributor

I also tried this will SampleServer7 (ArcGIS Enterprise 11.1) (https://sampleserver7.arcgisonline.com/server/rest/services/UtilityNetwork/NapervilleElectricV5/Feat...)

 

var credential = await AuthenticationManager.Current.GenerateCredentialAsync(new Uri("https://sampleserver7.arcgisonline.com/portal/sharing/rest"), "viewer01", "I68VGU^nMurF");
AuthenticationManager.Current.AddCredential(credential);

 

and with Enterprise 11.2 and got the same behavior that @JenniferNery got. Only one replica was created on the server.

Could you please try it against SampleServer7 and see what you get?

After this would be good to capture the request traffic (using Fiddler) to see what is the request sent to server, and maybe check what service settings are enabled to try to compare.

0 Kudos
JoeHershman
MVP Regular Contributor

This is integrated into a pretty elaborate offline data management tool, so just pointing to a service is a pretty significant amount of changes.

Do you have replica tracking on for these datasets used for the services?

Thanks,
-Joe
0 Kudos
TonyWakim
Esri Contributor

@JoeHershman , yes Replica tracking is enabled on the data behind the service we are using. 

Have you had the chance to test with a simpler test code against your service?

0 Kudos
JoeHershman
MVP Regular Contributor

@TonyWakim@JenniferNery  I did run against that services using just a user name and password login and I only see one new replica added to the service.

Are you using both hosted services in the test cases?  I am just trying to think of things different.  We are using a HANA database and the services use reference data, not hosted.

The way the application works is:

  • User connects to portal using an OAuth Authorization (that uses SAML in this case)
  • An interface is presented that allows the user to select the PortalItem to generate a replica from
  • The user selects an output folder, and the output path is created
  • The code above is used to create the replica.

I have looked at the Jobs folder while doing this and only see a single job created so I am not sure what process possibly creates the second replica.  But so far this seems to happen on every replica I generate.

Looking at other things, last night I ran my tool four times on a service I have (single feature class).  I have eight replicas show in the ArcGIS Server UI.  The first one in each set named Ags_Fs

JoeHershman_0-1700140683201.png

Another strange thing I notice, if I look in Pro the only ones I see are the ones that have none Ags_Fs names:

JoeHershman_1-1700140807805.png

 

 

 

 

Thanks,
-Joe
0 Kudos
TonyWakim
Esri Contributor

@JoeHershman would you be able to share a diagram of your HA configuration showing how you have it set up with server?

I would recommend you contact support to help you check the settings on your HA configuration to see if that is the cause of the behavior you are experiencing.

0 Kudos
JoeHershman
MVP Regular Contributor

@TonyWakim  I deleted that post because I jumped the gun.  After the first replica I generated which did not duplicate other replicas have duplicated.  So my thought of it having something to do with the single machine env. vs. a multiple machines server farm was incorrect

Thanks,
-Joe
0 Kudos
TonyWakim
Esri Contributor

@JoeHershman , No worries.

So far We are not able to reproduce this on our side; We are using latest Native Maps SDKs version; and have tried with two different versions of ArcGIS Enterprise on our side. 

Try to narrow down the cause of what you are seeing... Potentially one of two things:

- A service/server configuration issue

- A code issue with your application. (a specific version, or code issue...?)

You can either try your code against a different service (SampleServer 7 comes to mind since we tried that one); or try a simple test application against your service.

The code you shared with us does not reproduce this on our side; so if you have a simple application with that code (using latest Native SDKs nuget) and you can reproduce against your service then it is not a code issue, but probably a service/server issue.  That would help us narrow down where to look for the cause.

Using Fiddler to capture traffic and requests being sent to server will also help determine the call(s) being done from client to server.  Another source of information is the server logs; you can configure that with more verbose logging (specifically during testing this request) then try to create a new replica and monitor the logs on the server side.

 

 

0 Kudos