POST
|
Did you let GeoEvent Server Create the GeoEvent Definition for you? If not, let it create a new definition (name it something like 'devices-in-auto'). Once it has been created, make a copy of it and name the new copy something like 'devices-in'. Make a copy of 'devices-in' and name it something like 'devices-flat'. Now edit 'devices-flat' and remove the grouped fields (with the values you see above) and re-add those fields to the GeoEvent definition (there should no longer be any groups in your definition). Now go back to your service, update the input to use existing definition and choose 'devices-in', after the input, add a field mapper that maps 'devices-in' to 'devices-flat'. To get to the grouped items from above, use the . notation (e.g. group.level or group.rssi).
... View more
05-19-2021
04:31 PM
|
0
|
4
|
2125
|
BLOG
|
ArcGIS GeoEvent Server 10.9 offers many new and exciting improvements in usability, expanded analytic capabilities, and stability enhancements. At a high-level, the user experience for designing and maintaining all of your real-time event processing workflows has been greatly simplified. In addition, several stability enhancements were made to increase event throughputs and uptime. Let’s explore each of these in some more detail. To start, GeoEvent Server 10.9 provides a boost to your real-time event processing by improving the underlying event throughput for complex GeoEvent Services. This includes improvements to event handling, allowing event data to be routed and processed more efficiently, thereby, reducing system load and increasing event processing rates. Next, on the user experience side, many quality and usability improvements have been made when designing GeoEvent Services as well as in GeoEvent Sampler. In the service designer, the workflows necessary to create and maintain GeoEvent Services were refined even further, reducing the number of clicks necessary to complete a task. In GeoEvent Sampler, support for non-English languages has been improved. A new real-time processing element and several new analytic capabilities were added at this release. The new choice element can be added to a GeoEvent Service in place of a filter element. The new choice element offers a more refined approach to event routing, providing an IF, ELSE IF, …, ELSE approach to evaluating events. By using the new choice element, workflows involving many filter elements can be simplified and streamlined. Parallel Filtering Choice In addition to the new choice element, several processors were updated with new capabilities. The Field Mapper Processor has expanded capabilities to allow Field Calculator Processor functions in the field mapping. Now multiple calculations across many fields can be done all at once, in parallel. This new capability provides the opportunity to condense long chains of Field Calculator nodes down into a single Field Mapper node. Multiple Field Calculators Updated Field Mapper Also, the Incident Detector Processor now supports the optional ability to retain the source event’s original fields. This allows the Incident Detector to emit events with a combination of the original event’s field schema and the GeoEvent incident’s field schema. All these improvements in the analytic capabilities of GeoEvent Server provide an opportunity to drastically simplify your event processing workflows, contributing to improved stability and maintainability. And lastly, a deprecation notice. Support has been deprecated for multi-machine deployments where multiple GeoEvent Server instances coordinate through a single ArcGIS Server site. This is a deployment pattern we’ve encouraged customers to move away from for a little over a year now. Beginning with the 10.9 release, every instance of GeoEvent Server you deploy must run beneath its own ArcGIS Server with its own ArcGIS Server site. This extends the single-machine high-availability active/active and single-machine high-availability active/passive deployment patterns promoted by ArcGIS Server. The decision to remove support for multiple-machine / single-site deployments is based on observations over time that GeoEvent Server deployments which coordinate through a single ArcGIS Server site do not meet reliability objectives. In rare cases of complete hardware failure – where a single server node in a multi-machine deployment went permanently offline – the deprecated deployment pattern did provide fault-tolerance. More frequently, however, when a deployment was challenged by a disadvantaged network, or a machine was temporarily unavailable, or servers were restarted out of sync, the whole deployment could become unusable. Recovery was tedious and error prone, which led to promises that a system architecture would provide high-availability failing to meet expectations. As a result of this deprecation, the GeoEvent Gateway has been refactored to provide better resiliency and overall system stability for most users by removing cluster leader election and in-sync replication between peer brokers/consumers. This means that multiple instances of GeoEvent Server will no longer be able to synchronize a shared configuration or support a "clustered computing" architecture. But in the end, it achieves a better, more resilient, and more stable product. GeoEvent Server’s on-line help documentation has been updated with a new help topic: Deployment Considerations. In particular you might want to review the help topic: Strategies for scalability, reliability, and resiliency.
... View more
05-19-2021
09:49 AM
|
3
|
2
|
1391
|
POST
|
Hey @AdamRepsher_BentEar You can test your hypothesis outside of GeoEvent Server by doing a direct request against the REST api of the Feature Service from the machine GeoEvent Server is running on, outside of GeoEvent (query a layer in the REST end point with where = '1=1' in a browser and see how long it takes). If it takes more than 30 seconds, you can increase the timeout property on your GeoEvent input. If it returns no data, the issue is in the feature service. If it returns with data in less than 30 seconds, the issue may be inside your GeoEvent Server input.
... View more
05-19-2021
08:24 AM
|
0
|
7
|
2134
|
POST
|
Hey @JeffPope Can you please set the Logger com.esri.geoevent.processor.multicardinalfieldsplitter.MulticardinalFieldSplitter to TRACE and wait for the error to happen again. Then send me the karaf.log file (in the \data\ directory of your GeoEvent Server install folder). After the error occurs, you can reset the log level for that logger back to WARN. Thanks!
... View more
05-19-2021
08:19 AM
|
0
|
1
|
520
|
POST
|
Hey @MAGICMuscatineAreaGeographicIn At the moment GeoEvent doesn't support URL form encoded data (there is no OOTB adapter for it). GeoEvent does natively support XML, JSON, GeoJSON, and CSV, so you will need to convert the data into one of those formats before sending. If you cannot change the format of the incoming data, you will need to create a custom adapter using the GeoEvent SDK or a separate application to receive the form data, translate it into one of the supported formats, and forward it to GeoEvent.
... View more
05-19-2021
08:10 AM
|
1
|
1
|
860
|
POST
|
Hey @AdamRepsher_BentEar Yes, you are approaching this correctly. The ArcGIS Server user (by default arcgis) must have at least read privileges on the view(s)/table(s) in the database that are to be published in the web service. The database does not need to be a geodatabase, the user just needs that read-only access. For read only access, the web service can be a map service or a feature service. Once the service is created it needs to be owned by the ArcGIS Server/Portal user that is defined in the GeoEvent data store connection, or it can be public.
... View more
05-19-2021
07:26 AM
|
1
|
9
|
2137
|
POST
|
Hey @MassimoDragan1 You might try to leverage an RDBMS instead of GeoEvent to help with some of the state management and aggregation. Based on my quick read, you could GeoTag the records as they come in, then use standard SQL to create a view that summarizes the data (and even includes the polygon shape or a centroid for putting it on the map). https://community.esri.com/t5/arcgis-geoevent-server-blog/geoevent-tracking-asset-s-active-inactive-status/ba-p/902116 Best, Eric
... View more
04-30-2021
03:49 PM
|
0
|
0
|
745
|
POST
|
Hey @Anonymous User The IN operator is working for me given your provided sample. In your screenshot you are showing the = (equals) operator instead of the IN operator. If you set this up to use the following, it should work. Hiver_deneigement_zone IN ${Zones}
... View more
04-30-2021
03:43 PM
|
0
|
0
|
499
|
POST
|
Hey @GentryEwing1 Sorry, I haven't worked directly with that product and don't immediately recognize any of the protocols listed. But you might be able to make it work. Here is what to look for: 1. The interface you get data from should implement one of the standard transports that are OOTB with GeoEvent (HTTP, TCP, UDP, or Kafka). They could be either Client or Server connection types. 2. The data protocol is a format that is supported by GeoEvent OOTB (JSON, XML, CSV, RSS). 3. If GeoEvent must request the data, the data request provides a way to obtain data without modifying the request parameters (no updated timestamps or expiring session tokens). Ideally each request would also return an updated value, but this is not required. Hope this helps. Eric
... View more
04-30-2021
03:32 PM
|
0
|
0
|
738
|
POST
|
Hey @Mike_Quetel Booleans should be handled as either String or a numeric number (depending on your feature service and how you set it up). Import the GeoEvent Definition from the Feature Service you are writing to (delete the OBJECTID, GUID, and any other managed fields) then use a field mapper to map your events into that defintion before writing out to your feature service. If your fields are numeric, you'll need to use a field calculator before the field mapper to convert boolean into numeric. for boolean fields, I recommend you use a string because you can map a boolean field to a string field directly in the Field Mapper.
... View more
04-30-2021
03:21 PM
|
0
|
0
|
1145
|
POST
|
Hey @nasserhinai The error you are receiving indicates that the email transport that comes with GeoEvent has somehow failed and has been unloaded. You should try one of the following first. 1. Stop the GeoEvent Windows Service, delete the contents of the data folder in the GeoEvent installation directory (don't delete the data folder, just its contents and subfolders). Restart the GeoEvent Server Windows service. Check to see if the email output is working. 2. Re-run the GeoEvent Server installation and choose the 'Repair' option. After the installation is repaird, repeat 1 above. If neither of these fixes the issue, we will need to look at your configuration and your logs to see what is going on. Best, Eric
... View more
04-30-2021
03:10 PM
|
0
|
0
|
537
|
POST
|
Hey @SteinarVenning1 Please try the latest release r4 (updated March 31, 2021). It should be fixed now. https://www.arcgis.com/home/item.html?id=24770812a22e4feba56555aeafbf68ac
... View more
04-30-2021
03:05 PM
|
0
|
0
|
329
|
POST
|
Hey @GeoSolver You could export a list of email addresses to a file and use a Feild Enricher (File) to add the emails to a recipient field. So the file would contain one record "1,<longlistofemails>". Your event would need to have 2 fields added to it 'joinId' and 'emailAddresses'. Use a field calculator to set the 'joinId' field to 1. The Field Enricher (File) to join the email list then joins based on the 'joinId' field (which is set to 1 which matches the first row in the file). If the file with all the emails is too hard to maintain (for example if they change often) then you might be able to do the same thing on your feature layer but it might require a relational database. SELECT 1 as OBJECTID, STRING_AGG(email, ';') AS emailAddresses FROM Customers; Not sure what 9,000 emails concatenated together is going to do to GeoEvent. Best, Eric
... View more
04-30-2021
03:03 PM
|
0
|
0
|
511
|
POST
|
hey @Ctal_GISsquad The default time that geoevent creates is going to be UTC. So if your server's time is not set to UTC, the date will be offset according to the timezone you are in. To get around you can add/subtract your timezone offset from the date value. But that only returns the time assigned to the date back to midnight (or noon) and doesn't really get rid of it. To not display the time, you will need to rely on the web map to format the date field without a time. Alternatively, you could add the time you have from the call_created_time field (call_created_date - timeZoneOffset + call_created_time). This would result in a date in call_created_date field that had the proper date and time. That assumes the call_created_time is a local time (if it is in UTC you can omit the timeZoneOffset).
... View more
04-30-2021
02:51 PM
|
0
|
0
|
911
|
POST
|
Hey @GeoSolver There could be a number of things getting in the way here. We'll start with the first two that come to my mind: 1. You have posted that you are using http://localhost, so this should work. But if you are using https://localhost, you might want to switch to FQDN and import the certifcate used by the server into GeoEvent's ArcGIS Server. 2. The proxy server may not be working as expected. You can verify this using the GeoEvent loggers com.esri.ges.httpclient.Http and org.apache.http.wire set to DEBUG or TRACE. They will create a large volume of data for all communications so it is best to test with just your one output running. 3. Check the media type property in your output. Default is application/json, so you might check that the other end is expecting that. Another test you might run is to have the GeoEvent output write to another GeoEvent HTTP/JSON input. Good luck, Eric
... View more
04-30-2021
02:37 PM
|
0
|
0
|
605
|
Title | Kudos | Posted |
---|---|---|
1 | 02-05-2024 11:02 AM | |
1 | 09-14-2023 08:09 PM | |
2 | 05-13-2019 09:32 AM | |
1 | 01-20-2023 02:36 PM | |
1 | 01-20-2023 02:31 PM |