Latest Contributions by RJSunderman

‎09-15-2015

Lloyd - If you navigate to Site > GeoEvent > Connectors and search for "XML" ... you are not seeing the following two inbound connectors? These should be out-of-the-box at the 10.3.0 release. What do you see when browsing to the URL https://localhost:6143/geoevent/manager/version.txt (You should see the product version 10.3.0.4322) Are you able to locate the XML adapter's JAR file (xml-adapter-10.3.0.jar) down beneath the framework? C:\Program Files\ArcGIS\Server\GeoEvent\system\com\esri\ges\framework\adapter\xml-adapter\10.3.0 - RJ

‎09-10-2015

Hello Darryl - I don't have any references for you of someone who has developed a custom adapter for handling a response from a request made on a SOAP service. GeoEvent is fundamentally RESTful, meaning that we interact with services using REST requests. You might take a look at the thread Is it possible to send a SOAP request with GeoEvent? For background, here's what I know about the differences between REST and SOAP. In a REST query you might have some JSON (JavaScript Object Notation) in the body of the request, but often you do not. This is because everything you need to communicate to the service being queried is contained in the request’s URL as parameters. In this way a REST call is sort of like invoking a function with parameters you pass in the function call. SOAP is fundamentally different. It is XML based – as opposed to REST which more “object-oriented”, using JSON “objects” to pass information. When making a SOAP request you always have some sort of XML body which contains the authentication and request parameters. You get back an XML response which you then have to parse. SOAP fell out of favor primarily because XML parsing is considered expensive. A JSON response from a REST service request would, of course, have some sort of header. But the response is primarily a single object or a list of objects expressed as JSON. This object (or list of objects) returned from your request is something GeoEvent would consider an event (or a list of events). XML can also be used to represent an event or a list of events – and we introduced the XML adapter in the 10.3 product release to handle that sort of message content. So a SOAP / XML response might be something the XML adapter out-of-the-box could parse, but since the XML is not “object-oriented” (like what we usually see with JSON) there is going to be quite a lot of work needed to delve into the XML response you receive and pull out the event data you are looking for. The amount of work required would probably make using an out-of-the-box GeoEvent Service filters and processors impractical. You would probably need to develop a custom processor if you wanted to process a SOAP response to extract event data within a GeoEvent Service. Alternatively you could develop a custom adapter to parse the SOAP / XML response and construct a set of GeoEvents your adapter would then pass into your GeoEvent Service for some basic filtering and/or processing. Which brings us back to your original question, has anyone done this? So … the recommendation is to avoid services which use SOAP. In addition to a custom processor or custom adapter you will probably also have to develop a custom transport to handle service polling, since you will need to construct the XML body the SOAP service expects to authenticate and communicate your request. This is definitely not something you can just configure GeoEvent to do. More than likely it is going to be a development project in which you use the GeoEvent SDK to develop custom components and extend the product to support SOAP – not in general – but for a specific service which you want to poll for data. Hope this information helps - RJ

‎09-10-2015

Hello Adriana - Are you using a GeoEvent output -- either the Add a Feature output or the Update a Feature output -- to make edits to your feature service? If so, you can review the Debugging the Add a Feature / Update a Feature Output Connectors blog to see how to configure GeoEvent to log debug messages which should tell you something about the JSON being sent in the requests to Server and the responses returned from Server. If you are not using GeoEvent and the application you are developing is making its own requests on a feature service's .../FeatureServer/0/addFeatures or .../FeatureServer/0/updateFeatures REST endpoint, you might want to ask your question on the Web AppBuilder for ArcGIS forum. Someone there can provide you advice on developing your web application. Hope this information helps - RJ

‎09-02-2015

Jon - Thank you for your feedback and taking the time to submit this enhancement as an idea. The product team has created a work item with the following proposed acceptance criteria. You can refer to this as item #960 in the product team's GitHub repository if you want to provide additional feedback or inquire as to the enhancement's status. The property UI will have a new dropdown property for Update Sequence Time Field. From the dropdown, user can choose an existing esriFieldTypeDate attribute from the the feature layer. If the new property is left unspecified, the behavior will be as it is today; the date/time an event is received will drive whether or not a request is made by GeoEvent to update a feature in the targeted feature class. If the user chooses a field (e.g. a feature attribute named 'timefield') the connector will do the following: -- A -- Update its internal cache when an event with a given TRACK_ID is received only if the event's 'timefield' value is greater than an event record already in the cache. -- B -- When iterating through its internal cache to create a transaction request, consider not only each event's TRACK_ID but also the event's 'timefield' value so that features in the targeted feature class are only updated if the event's date/time is greater than the date/time of the existing feature.

‎08-31-2015

Hey Allen - Take a look at Ben Saunders's Blog: Orphan Tracks in GeoEvent Processor The GeoEvent 'Add a Feature' and 'Update a Feature' output connectors can be configured to delete "old" features, if you have a field of type Date to which you can have the output refer. The output will periodically (every nn seconds) query the feature layer to which it is adding or updating features for any records older than mm minutes -- and delete them. But you can't always assume that a record should be deleted just because a date/time stamp hasn't been updated for mm minutes. Nor do you always have a date/time stamp to which you can refer. Ben proposes allowing real-time analytics to decide when a record is "closed" or "obsolete" and writing a value into a specific event attribute field. Then have a 'Poll an ArcGIS Server for Features' input periodically poll for features which are "closed" or "obsolete" ... and set the input's 'Delete Polled Features' property to Yes. The beautiful thing is you don't event have to do anything with the records polled by the input. You could write them out to a confirmation log that these records are being deleted if you want ... but the input's only job is to identify records to be deleted, without requiring a Date field, and delete the identified records. - RJ

‎08-31-2015

Hello Evan / Greg - I would remove the line specifying the attribute field names from the CSV file you are writing into the folder the 'Watch a folder for new .csv files' inbound connector is watching ... better to include only the actual event data in the file and leave out the attribute field names. In a reply to Greg, Evan cross-references an older thread, watching a folder with csv files, in which I state: "the first two lines of the CSV file are reserved for a comma separated list of field name and a comma separated list of field data types - your actual event data needs to start with the 3rd line of the text file." But then in this thread I suggest the opposite, to remove specification of attribute field names from the CSV file. So which is it, you're asking. Should a CSV file include a two-line header with field names and types, or shouldn't it? My apologies for the confusion. In the older thread I must have been thinking of when a CSV file is used as the source of event enrichment, not when the CSV file is used as the source of the event data. An enrichment file would need the header rows to specify field names and field types. You would not want a CSV input file to include anything more than the (comma) delimited data values. Evan is correct, above, when he suggests that the OS level user responsible for running the GeoEvent Windows service is the account which needs permission to access a registered folder. I don't remember if it was at 10.2.2 or a later release that we added visual indication of the apparent permissions on a registered folder to the Site > GeoEvent > Data Stores page in Manager. That particular enhancement might help clear up potential issues with whether or not an input connector will be able to retrieve data from a registered folder. Also, Greg points out that when registering the system folder, the user-interface's default is to place a value 'input' in the 'Input Directory' parameter. I always remove this value and leave the 'Input Directory' parameter unspecified. The default would only work if you wanted your 'Watch a Folder for New CSV Files' input to look for a sub-directory named input beneath a registered system path C:\GeoEvent\csv (for example). When working with file-based input and output (and enrichment) I usually register separate folders: GeoEvent_Input -- C:\GeoEvent\input GeoEvent_Output -- C:\GeoEvent\output GeoEvent_Enrich -- C:\GeoEvent\enrichment I don't configure my 'Watch a Folder for New CSV Files' to expect an 'input' sub-directory, and I don't allow it to 'Include Subfolders'. Finally, please keep in mind that the GeoEvent Extension generally supports RESTful data streams. The inputs capable of watching a system folder for files have some significant limitations and are generally intended to prove that real-time analytics you have designed in a GeoEvent Service behave as you intend. Moving toward production we expect real-time data feeds to arrive via HTTP/POST or as replies to queries you make on an external server's URL. Best Regards - RJ

‎08-31-2015

Hello Ben - Unfortunately the capability I think you are looking for was built into the 10.3.1 release. It might be available at the 10.3.0 release ... but is not available in the 10.2.2 product. Similar to K's post Re: Anyone have any luck with passing a user name and password the the Poll an External Website for XML? (which I saw you marked as helpful) ... in which she's configuring a parameter 'Parameters' exposed by the input ... the 10.3.1 release exposes a new 'Header Parameter Name:Value List' parameter you can configure with a comma separated list of Name:Value pairs you want GeoEvent to send with each of its requests. Keep in mind that because just about everything that GeoEvent does is RESTful there is nothing that prevents an ArcGIS Server / GeoEvent 10.3.1 instance from polling an older ArcGIS 10.2.2 Server and/or geodatabase ... or using GeoEvent to update features exposed through services published on a 10.2.2 ArcGIS Server. Sometimes upgrading a production system from 10.2.2 to 10.3.1 is not an option. However, you can stand-up a second ArcGIS Server site (running 10.3.1) which has the latest GeoEvent Extension installed. The obvious downside here is that a second ArcGIS Server site requires a second license; but if you have an ELA that might be an option for you. - RJ

‎08-31-2015

Thanks Peter for the follow-up. It looks like somehow there are two "RabbitMQ" messaging service / platform services configured, each with its own GUID / id. I don't know how this would happen; maybe there is an OS factor to consider in issue replication. I think I would expect some sort of failure if GeoEvent went searching for a platform service of type "MESSAGE_BUS" and found more than one candidate. I don't know that I would have expected the ACCESS_REFUSED log-in failure ... but in any case you're tracking to the root cause of the issue. Good luck - RJ

‎08-31-2015

Hello Matthew - It might help if you think of a "connector" as pairing a specific "adapter" with a specific "transport". It is the transport's job it to deliver a payload (raw bytes) to an adapter. It's the adapter's job to extract data from the received stream and use a GeoEvent Definition to create a GeoEvent. The 'Receive Text from a TCP Socket' inbound connector you mention does not reach out to a IP address to interrogate a device. It opens a TCP socket (as a server application) so that some external client can send delimited text to that socket. The TCP socket in this scenario is the transport. The out-of-the-box text adapter is what is expecting simple delimited text that it can parse in order to retrieve data values and construct a GeoEvent. The GeoEvent Extension does not have an ODBC / JDBC connector you can use to retrieve data directly from an RDBMS table. Please take a look at the following thread: Re: GeoEvent process Oracle/SQL connector There are exercises in the product introduction tutorial, available here, with the other product tutorials, which introduces you to the 'Receive Text from a TCP Socket' inbound connector and the GeoEvent Simulator you can use to send data to the input. If we shift our focus away from the TCP socket protocol for a moment, the 10.3.x release has out-of-the-box inbound connectors which allow a data provider to HTTP/POST data directly to REST endpoint hosted by the GeoEvent Extension. Could you configure your AVL to HTTP / POST position data as generic JSON or generic XML to a GeoEvent REST endpoint? Could you develop an external Python script to retrieve records from your database and then POST the data to GeoEvent? Using an HTTP / POST mechanism to send data to GeoEvent is not AVL specific -- and that's sort of my point. When considering GeoEvent you need to identify how the extension should receiving a feed from an external system, or how you can make a REST request to an external system that will return data in a well known format (such as delimited text, generic JSON, geoJSON, or generic XML). Once you've had a chance to go through the product introduction tutorial, maybe you could take a look at the Sierra Wireless RAP Connector tutorial. This would only be useful if you happen to be using Sierra Wireless gateway devices in your vehicles, but the exercises will underscore the concept of how GeoEvent receives data, this time in an AVL context. There are also a number of commercial AVL connectors we could look at: CompassLDE (CompassCom), Zonar, Networkfleet … Hope this information helps - RJ

‎08-31-2015

Hello Jamal - The message your IE browser is displaying ("page can't be displayed") indicates that the CXF framework has not initialized correctly. This what handles all of the REST endpoints beneath https : //localhost:6143/geoevent/. Because the CXF framework is the very last component to initialize, we are going to have to look around a bit to try and identify what exactly might be failing. Are you working with the latest release (10.3.1) of GeoEvent? Do you see any errors in either the karaf.log or wrapper.log (found beneath C:\Program Files\ArcGIS\Server\GeoEvent\data\log) ... particularly with regard to "container" or "bundle" unresolved dependencies? Are you sure that you have the GeoEvent Extension licensed on this server? Messages logged in the karaf.log from LicenseChecker and LicenseEnforcer will indicate an error if the product is not licensed. If you try to browse to https : //localhost:6143/geoevent/manager/ from another browser (Chrome or Firefox) ... do you see a message other than "page can't be displayed"? Are you running any anti-virus software? McAfee On-Access Scanner has proven to cause problems with GeoEvent startup (refer to Esri Support KB Article #44817). How many bundle files do you see in the C:\Program Files\ArcGIS\Server\GeoEvent\data\cache folder? For the 10.3.1 release I'm expecting to see 370+ numbered bundle sub-folders (bundle0, bundle1, bundle2 ... bundle371). What files do you see in the product's configuration store? C:\ProgramData\Esri\GeoEvent\: zookeeper (folder) zookeeper.properties (text file) zookeeper-dynamic.properties (text file) Does the zookeeper.properties identify a dataDir beneath C:\ProgramData\Esri\GeoEvent\zookeeper\default ? Is there a server identification string like server.1=MY_MACHINE:2182:2190:participant;0.0.0.0:2181 in the zookeeper-dynamic.properties? Can you identify the PID for the java.exe process running GeoEvent? In task manager, look for the processing running as the user used to run the GeoEvent Windows service whose Command Line contains the switch -Dkaraf.home, or look in the instance.properties file beneath C:\Program Files\ArcGIS\Server\GeoEvent\instances for the item.0.pid value. As a user with administrative privileges, from a Windows command line, run a netstat -a -o command to show you all of the active TCP connections and ports on which particular processes are listening. In my example below, the java.exe process running my GeoEvent is PID 11608 ... so I can search through the netstat results to find the ports GeoEvent is using: TCP 0.0.0.0:1100 HOSTNAME:0 LISTENING 11608 TCP 0.0.0.0:2181 HOSTNAME:0 LISTENING 11608 TCP 0.0.0.0:6143 HOSTNAME:0 LISTENING 11608 TCP 0.0.0.0:6180 HOSTNAME:0 LISTENING 11608 TCP 0.0.0.0:8101 HOSTNAME:0 LISTENING 11608 TCP 0.0.0.0:44445 HOSTNAME:0 LISTENING 11608 TCP 0.0.0.0:64009 HOSTNAME:0 LISTENING 11608 TCP 10.27.51.242:2182 HOSTNAME:0 LISTENING 11608 TCP 10.27.51.242:2190 HOSTNAME:0 LISTENING 11608 If all of the above check-out ... you might try an in-place removal of the product's configuration store and run-time generated files, then restart GeoEvent: Stop the GeoEvent Windows service Delete all files and folders beneath C:\Program Files\ArcGIS\Server\GeoEvent\data Delete all files and folders except certs beneath C:\ProgramData\Esri\GeoEvent Restart the GeoEvent Windows service Hope this information helps. You might need to contact Esri Technical Support and open an incident. Working with technical support will probably be better than exchanging messages on the forum for this issue. I'm happy to answer questions on any of the above, and please post if you're able to identify the issue. - RJ

‎08-25-2015

I'm experiencing the same issue. Server is very unresponsive. Registered geodatabase data stores refuse to validate. Requests to stop and delete map / feature services spin for many minutes before returning control to the user -- sometimes returning with the "deleted" items still listed in Manager. A refresh of the ArcGIS REST Services Directory will eventually show the items I've selected to delete as having been deleted. My Server log is filled with Unable to process request. Error handling service request :Failed to register the activation group. Failed to construct instance of service 'SampleWorldCities.MapServer'. Failed to register the activation group. This after (eventually) being able to delete all other map / feature services. Any advice? - RJ

‎08-20-2015

Thank you Peter. If you'll send me the technical support incident number I'll work to follow-up with my POC in Esri Support. Sorry, but I'm having trouble finding it in Esri Support's database... I've been told by the Server product team that the ACCESS_REFUSED - Login was refused using authentication mechanism PLAIN error message is returned when: The guest account of Rabbit MQ is used to log-in. A RabbitMQ client connection to the RabbitMQ service is attempted with a different version number. The Server team has indicated that the first cannot be the case as we (Esri) delete the guest account and create a new account for log-in. The second option, then, could occur when a client (GeoEvent or an external / non-Esri app) whose RabbitMQ version is different than the one used by the ArcGIS Server platform service attempts a connection. For example, an ArcGIS Server 10.3.1 machine I accessed specifies that version 3.2.3 of RabbitMQ is being run (https://esri-server:6443/arcgis/admin/system/platformservices/?f=pjson). If a client leveraging a JAR file from RabbitMQ 3.2.0 attempted to connect, we'd receive the ACCESS_REFUSED error. I don't see how this can be the case, though, if GeoEvent is the only client attempting a connection. Let's plan on using the technical support incident to collaborate further. I can post a SUM back here if / when we figure out what's going on. Please feel free to post back to this thread if you discover a work around or solution yourself. Thanks - RJ

‎08-20-2015

I've configured a 'Poll an ArcGIS Server for Features input to 'Get Incremental Updates'. Is there a way to prevent the input from polling all of the features in a feature class when GeoEvent Server is restarted? (Updated August 2023) The short answer is: No. When GeoEvent Server's services are restarted (or the server on which GeoEvent Server is running is rebooted), inputs which poll an ArcGIS Server map/feature service for feature records lose a key value (maintained in memory) used by the input to determine which feature records are new or recently edited. Following a system restart the input must retrieve a complete feature record set from the source map/feature service in order to iterate through the data records, find the greatest object identifier or date/time value, and cache this value for use when making the next query. This means that feature records ingest, adapted, and processed previously will be processed a second time. This key value can also be lost simply by editing the input's configuration. Suppose that an existing Poll an ArcGIS Server for Features input were modified, or deleted and replaced with a new input. These actions may also cause the in-memory key used to poll for feature records incrementally to be lost resulting in feature records previously processed to be ingest, adapted, and processed a second time. When is this likely to be a problem? The capability to 'Get Incremental Updates' is unique to the Poll an ArcGIS Server for Features inbound connector. Do not confuse this input's incremental polling capability with the 'Receive New Data Only' parameter available when configuring a Poll an External Website for JSON input for example. The latter polls external server's web services (vs. an ArcGIS Server's map/feature services) and relies on the external web service to include a specific HTTP property (Last-Modified) in its response header. (More information on this is available in comments in the thread Re: Receive RSS Inbound Connector.) The issue we are exploring here deals only with the Poll an ArcGIS Server for Features input, or potentially a custom input you develop using the GeoEvent Server SDK which uses the FeatureService transport to poll an ArcGIS Server map/feature service. The input's unique ability to poll only for newly added or recently updated feature records can be useful when you do not want to ingest, adapt, and process feature records which have been processed previously and you do not want to have to delete previously processed feature records from the data source. This capability is limited, however. The ability to poll incrementally is not resilient when it comes to service restart or server machine reboot. Not all real-time event record processing solutions you configure will exhibit a problem if a server machine is rebooted or edits to an input obliterate a key value cached in memory. Solution architects must recognize, though, that when an input loses its cached key all available feature records from a feature service must be polled and processed a second time. This duplicative event record processing might not be a problem for a solution configured to update feature records using data from processed event records. Such a solution is simply going to update the target feature records with data already held in those feature record’s attributes. A solution which sends e-mail notifications, on the other hand, is different. If a server machine were rebooted, and a GeoEvent Server input configured to poll only newly added (or recently updated) feature records, and the input were to ingest and adapt a feature service’s complete feature record set a second time, then re-processing some number of dozen (or hundred, or thousand) feature records would generate duplicate e-mail notifications for every data record that was re-processed. Sending duplicate e-mail notifications every time a server machine is rebooted is obviously not ideal. Are system reboots the only time polling incrementally is likely to be a problem? No. The Poll an ArcGIS Server for Features input is also vulnerable when using object identifiers to determine which feature records have been recently added. A solution configured to poll only newly added feature records based on a database feature record’s object identifier can fail when ArcGIS Server invokes a mitigation strategy intended to support concurrent editing. In order to support multiple concurrent editors, ArcGIS Server assigns each editor a different block of object identifiers. One editor might create feature records with object identifiers in the range 1, 2, 3, ... 100. A second editor will be assigned a different range of identifiers allowing feature records to be created with object identifiers 401, 402, 403, (etc). A third concurrent editor will be allowed to create feature records with object identifiers 801, 802, 803 to avoid race conditions where each editor asks what the next available OBJECTID is and proceeds to create a feature records with (potentially) an identifier being used by another editor concurrently. If you configure a Poll an ArcGIS Server for Features input to poll incrementally based on OBJECTID, and the value ‘803’ from the third contributor is cached as the key to use when determining newly added feature records, it is possible that GeoEvent Server’s input will never poll feature records created by the first or second editors whose assigned object identifier range(s) are less than the cached key. Recommended Approach When a solution needs to be more resilient to system restart, or operate independently of feature record object identifier values the recommended approach, rather than configuring a Poll an ArcGIS Server for Features input to conduct incremental polling, is to write data into the feature records being polled which mark individual feature records as having been processed. This way, regardless of if or when GeoEvent Server’s services are restarted, its server machine is rebooted, or edits are made to feature records by concurrent editors, the history of which feature records have been processed is stored in the geodatabase. What you want to do, essentially, is add an attribute field to your map/feature service’s schema named something like hasBeenProcessed. Configure the feature service to write a default value ‘0’ into this field when new feature records are created, then as part of a GeoEvent Service configure your event record processing to overwrite the hasBeenProcessed attribute field’s value with a ‘1’ to mark it as a feature record you do not want a GeoEvent Server input to include in a future poll. You do this by changing the input’s Query Definition from its default 1=1 to hasBeenProcessed < 1. If you ever do find that you want to re-process a feature record, perhaps because some important attributes of the data record have been updated or changed, just make sure the feature editing workflow returns the hasBeenProcessed attribute back to its initial/default value ‘0’ and GeoEvent Server’s input will automatically include that feature record in its next poll. - - - If you have other approaches you have developed to deal with this particular behavior, your comments are welcome. Please also consider information and user comments in these other threads: Question regarding "Incremental Update" workarounds, custom components? Using a partial GeoEvent Definition to update feature records Poll an ArcGIS Server for Features: Methods used to identify incremental updates As always, I hope this information helps. - RJ

‎08-20-2015

Hey Peter - I'm not sure that RabbitMQ's restriction of only allowing guest to log-in via a loopback interface (i.e. localhost) is relevant here. ArcGIS Server is exposing RabbitMQ as a platform service. If we log-in to the ArcGIS Server Admin API we can obtain a user-id and password from the platform service and use those credentials to log-in to the RabbitMQ management console, for example. I've verified that I can do this from a remote machine. For this issue, reinstalling the GeoEvent product is not going to do anything for us. The platform service is created by ArcGIS Server during its product installation. GeoEvent is using the platform service created by ArcGIS Server. If we end up having to re-install anything to fix RabbitMQ it will be Server, not GeoEvent. Are you experiencing this issue on a single server, with localhost the only machine in the ArcGIS Server site's default cluster? To be clear, the RabbitMQ platform service must be available whether or not your site architecture consists of a single machine or multiple machines participating in a cluster -- I just want to be clear about your system setup. - RJ

‎08-19-2015

If you're able to export your product configuration, and are comfortable with the concept of editing XML, you could also edit the exported XML to delete the geoEventDefinitions node (removing all of its sub-nodes from the XML), reset your GeoEvent product configuration, then import the edited XML to bring back all of your inputs, outputs, GeoEvent Services (etc.) ... without importing the unwanted GeoEvent Definitions. - RJ

Online Status	Offline
Date Last Visited	yesterday

My Ideas

Latest Contributions by RJSunderman

Re: XML input connector - 10.3.0

Re: SOAP Input

Re: DotNet Proxy Configuration - Feature service not showing up

Re: GeoEvent Processor - Update Feature, include datetime check

Re: Is there a way to delete records from a Feature Layer?

Re: Problem with 'Watch a folder for new .csv files'

Re: Poll an External Website for JSON - with credentials

Re: RabbitMQ - ACCESS_REFUSED - Login was refused using authentication mechanism PLAIN

Re: Creating Input for AVL System

Re: Unable to start the Geoevent Manager,

Re: Failed to register the activation group during recycle

Re: RabbitMQ - ACCESS_REFUSED - Login was refused using authentication mechanism PLAIN

Polling feature services for "Incremental Updates" (Updated August 2023)

Re: RabbitMQ - ACCESS_REFUSED - Login was refused using authentication mechanism PLAIN

Re: Batch delete Geoeventdefinitions 10.3.1

Re: GeoEvent input connector using token authentic...

Re: Updating the Status of a Fire Unit

Re: Is there a way to delete records from a Featur...

Re: GeoEvent-Poll an External Website for JSON

Re: GeoFence sync is not detecting deleted feature...

ArcGIS Analyse