Latest Contributions by RJSunderman

Hello David - Please confirm the version of GeoEvent Processor that you are running. To do this, first sign-in to Manager then change the URL in the browser window from https://<host>:6143/geoevent/manager/index.html to https://<host>:6143/geoevent/manager/version.txt If the version information displayed resembles the following, you are running the initial release 10.2.0 which did not include the ability to design and publish GeoEvent Services from within the GEP Manager. Please consider upgrading to the latest product release 10.2.2 10.2.0.1155 10.2.0.1155 (10.2.0 Patch 1): Fixed - GeoEvent Manager - Chrome Browser issue of showing blank pages.  Using Dojo 1.6.2. If you are running either the 10.2.1 release or the 10.2.2 release - please reply back and we can investigate further. - RJ ... View more

Hello Tom - No, you should not need to build the source from the GitHub site. Not unless you find that the sample is not doing precisely what you want and you want to modify the source to customize the processor sample. If copying the JAR files extracted from the 10.2.x ZIP archive downloaded from the Gallery into the GeoEvent Processor's ...\deploy folder does not work, you might try explicitly adding them using the Manager: 1)  Launch GeoEvent Processor Manager 2)  Navigate to Site > Components > Processors and click 'Add Local Processor' 3)  Locate the buffer-processor-10.2.0.jar extracted from the 10.2.x ZIP archive downloaded from the Gallery 4)  Click 'Add' to add the selected JAR to the GeoEvent Processor framework You should see a message at the top of the Manager indicating that the custom processor was loaded successfully. If the BufferProcessor does not display in the Site > Components > Processors list after a few seconds, try refreshing the browser's display. I had to download and import the GeoEventDefinitions-GeometryProcessors.xml: 5) Browse to https: //github.com/Esri/solutions-geoevent-java/tree/master/data/configurations 6) Copy the GeoEventDefinitions-GeometryProcessors.xml file content to create a local XML file on your system 7) Navigate to Site > GeoEvent Processor > Configuration Store and click 'Import Configuration' 😎 Select the GeoEventDefinitions-GeometryProcessors.xml file and click 'Import' 9) Navigate to Site > GeoEvent Processor > GeoEvent Definitions You should see event definitions for buffer, ellipses, and rangefans listed. From there I was able to use the GeoEvent Simulator with a configured TCP/Text inbound connector to simulate events. I designed a simple GeoEvent Service incorporating a Buffer Processor. I mainly kept the default values for the processor. I specified 2500 meters as a constant buffer radius. I accepted the default WKID values for the incoming data (whose coordinates are WGS84), processor WKID (3857 is a spherical Mercator projection popular with web services), and output (project back to WGS84). I elected to send GeoEvents from the Buffer Processor to a GeoEvent cache, just so that I could review a JSON representation of the processor's output. [ATTACH=CONFIG]33939[/ATTACH] ... View more

Hello Tom - There are examples of a couple custom processors on the Esri" rel="nofollow" target="_blank">http://links.esri.com/geoevent-gallery]Esri Gallery along with the different connectors and product tutorials. I think the Processor" rel="nofollow" target="_blank">http://www.arcgis.com/home/item.html?id=a2f546a5cbb54e32a3218e5ded3f650a]Processor - Geometry Processors for GeoEvent Processor offering might be what you are looking for. - RJ ... View more

Hey David - I think the GeoEvent property you want to use is $RECEIVED_TIME ... not $ReceivedTime.  If you specify $RECEIVED_TIME as the Field Calculator expression, you should be able to time stamp each GeoEvent received from the Poll an ArcGIS Server for Features inbound connector with the server's current date/time. Correction:  When using a Field Calculator you need to use the functions receivedTime() and currentTime() as Vlad indicates below. Apologies for the misdirection.  - RJ I don't know that these "macros" are well documented ... the easiest way I know to find them is to review the list presented when configuring a filter expression. That dialog includes the attribute fields of known GeoEvent Definitions, known event field tags, and the GeoEvent property values (e.g. "macros") you can use in expressions. [ATTACH=CONFIG]33899[/ATTACH] - RJ ... View more

Hello Tom - The screenshot you took of the GeoEvent Definition generated by the inbound connector is indicating that location is a group containing two elements. The first element type is a String, the second element coordinate is a list of Double values. The "infinity" is how GEP indicates an element whose cardinality is "many". When coordinates are in a list, you need to specify the list index from which the coordinate value can be obtained. In your example you would retrieve the X Geometry Field from location.coordinate[1] and the Y Geometry Field from location.coordinate[0]. Note that I'm assuming the value 34.854503 is "latitude" and the value -117.087665 is "longitude". The list index is zero-based. Please refer also to the forum thread Is" rel="nofollow" target="_blank">http://forums.arcgis.com/threads/109508-Is-there-an-expression-for-converting-values-of-longtitude-and-latitude-into-a-point]Is there an expression for converting values of longtitude and latitude into a point. Hope this information helps - RJ ... View more

Hello Keren - An example of the functionality to which Mark is referring, Build Geometry From Fields can be found in 'Module 2' of the recently updated Introduction to GeoEvent" rel="nofollow" target="_blank">http://www.arcgis.com/home/item.html?id=265c334a47994dcc95e1bd57cf20e98e]GeoEvent Processor tutorial. Look on pages 26 and 27 in the exercise "Making Features Come Alive". If your coordinates are expressed as attributes within a group, as in Mark's example, you retrieve them from the JSON structure by name. If the coordinates are in a list, as illustrated below, you need to specify the list index from which the coordinate value can be obtained. {     "iss_position": {         "coordinates": [             -127.632425,             44.163747         ]     },     "message": "success",     "timestamp": 1400010196 } Given the JSON above, you would specify the X Geometry Field be taken from iss_position.coordinates[0] and the Y Geometry Field from iss_position.coordinates[1]. Hope this information helps - RJ ... View more

Hello Jordan - How many events per second is the GeoEvent Simulator you are using sending to GeoEvent Processor? Are you using the Update a Feature or the Add a feature outbound connector to update the feature service? Updating features can be expensive if the target feature service contains many thousands of features. This is because GeoEvent Processor must identify the feature to be updated by performing a full table scan querying for the feature's unique identifier to obtain the ObjectID of the table row before it can POST the update. There are a couple of things you might try to help narrow the scope of the problem: Reduce the number of events being sent to see if the problem is with data rate. Switch to use the Add a feature outbound connector to see the problem is with adding records vs. updating records. Specify a smaller number (50, 10, or even 1) for the outbound connector's Maximum Features Per Transaction parameter to see if updating the feature service with smaller batches helps. Check to make sure that there are no errors with the event data, such as a string which exceeds the maximum length allowed by the feature service or an integer value being sent which exceeds the range of the feature service's target field. You might also use the GeoEvent Processor's log to see how many milliseconds (or seconds) elaspse between GeoEvent Processor's POST to retrieve information and its POST to update the features. If there are any errors in these transactions, you might also find them in the log. First, from GEP Manager, navigate to the Logs page and click �??Settings�??. Select 'Debug' and enter the following logger item to debug: com.esri.ges.transport.featureService.FeatureServiceOutboundTransport. Don�??t forget to set this logger item back to ERROR, especially if you have thousands of events being sent to GeoEvent Processor. The logging statements generated at this level have the potential to produce log files which are quite large. If you edit the C:\Program Files\ArcGIS\Server\GeoEventProcessor\etc\org.ops4j.pax.logging.cfg configuration file you will see this logging setting persisted. If you have trouble using the GeoEvent Processor's Logging utility, you can always edit the configuration file directly (as an admin, since its under Program Files) to reset the logging level. Also, you might find it easier to view the log in a text editor. Look for the log file in the C:\Program Files\ArcGIS\Server\GeoEventProcessor\data\log folder. When reviewing the logs, you are looking for lines with the following logger entry:  com.esri.ges.framework.transport.featureservice-transport. Key phrases you will be looking for include: querying for missing track id Posting to url Response was At the debug level you should get a copy of exactly what is being sent/posted to the server. The query to get the object identifiers, for example, will look something like:   Posting to url : http:// �?� FeatureServer/0/query with parameters ... FlightNumber IN ('SWA1568','SWA510' �?� You should be able to see the JSON being sent to Server by each GEP transaction. You may need to copy/paste it into something like http://jsonlint.com/ to format it so you can read it. You can look at the timestamps on each log entry to get a feel for how long the different transactions with Server are taking. The illustration below is an example of what you want to dee in the logfile. Notice the latency in the last two DEBUG statements is about 325 milliseconds. If GeoEvent Processor is being fed a large number of events every second, it may be that transactions are taking to long and Server simply cannot keep up with the data being fed to it from GeoEvent Processor. [ATTACH=CONFIG]33629[/ATTACH] Hope this information is helpful - RJ ... View more

Hello Mark - If an Incident Detector processor has been configured to create "continuous" incidents, the management of the incidents is not handled by the individual processors in a GeoEvent Service. It is handled by an "incident manager" at the product level. So, once an Incident Detector processor has created an incident in response to a received event which satisfies the processor's opening condition, the only certain way to "reset" is to stop and restart the GeoEvent Processor - as you observed, cycling the GeoEvent Service which contains the processor is not sufficient. An ongoing, open, incident will only be closed if:  1) the processor"?s closing condition is satisfied by a received event; 2) the incident expires without update (depends on the Incident Detector processor"?s expiry time setting). The number of "open"� and "closed"� incidents the cache is allowed to contain is configurable. You would need to update the com.esri.ges.incidents.cfg file in the "�\GeoEventProcessor\etc product folder and restart GeoEvent Processor to do this. Reducing the allowable number of "open"� and "closed"� incidents does not "reset"� incident detection, but for testing and development, if you knew exactly how many unique incidents a given test would create, you might use this to force GEP to purge its cache between tests or test iterations. You also might find it helpful to use the administrative REST endpoint to look and see which incidents are currently in the product"?s cache, which are "open"� and which are "closed"�. Navigate to https://<server>:<port>/geoevent/admin/incidents in a browser window to view a snapshot of the incident cache. Also, please be aware that we recently identified a bug in which ongoing incidents, created by an Incident Detector processor, are orphaned when any property of any node in the GeoEvent Service containing the processor is changed and the GeoEvent Service is republished. The fault will manifest itself when the orphaned incidents expire; if the GeoEvent Service has an Incident Detector processor with the same name as the processor which originally created the incident, the "new"� instance of the processor (created when the service was republished) will be notified. The result is that an active, ongoing incident with the orphaned incident"?s TRACK_ID will be updated as closed, then updated again when a new event is received "� so you might see a "blip"� as the Geometry associated with the expired incident asserts itself if you are observing the incident Geometries on a map. We"?re working to address this with the 10.3 product release. Please let me know if you have any questions with the information above. Thanks - RJ ... View more

Hello Peter - I remember that work was done for the 10.2.1 release which changed how different Server connections were registered - ArcGIS Online (AGOL) being different than an on-premises / local ArcGIS for Server. This work was continued and additional changes were made for the 10.2.2 product release. Is it an option for you to try registering your AGOL connection using SSL with the latest product release (10.2.2)? - RJ ... View more

Hello Andreas - The text in the exception "Unable to intialize bean upgradeAction" suggests to me that something has run afoul such that GeoEvent Processor does not recognize a configurable element and is trying to "upgrade"� the element to work with the 10.2.1 product release you are running. Have you deployed any custom components? Added any connectors from the Gallery to your product? If you stop the Windows service which is running GeoEvent Processor, and then delete the files/folders in the following two directories, you should effectively reset the product. The files/folders you delete will be rebuilt when you restart the GeoEvent Processors"? Windows service.   C:\ProgramData\Esri\GeoEventProcessor   C:\Program Files\ArcGIS\Server\GeoEventProcessor\data 1) Delete everything in the product"?s configuration store. This is everything beneath the "�\Esri\GeoEventProcessor folder except the certs sub-folder. (You can delete certs as well, but you"?ll have to then go through the process of importing the GEP certificate as trusted.) These are all of your configured inputs, outputs, GeoEvent Services, GeoEvent Definitions, registered connections (Server and System Folders) "� etc. It is likely that something in here is what GeoEvent Processor is trying to "upgrade"�. 2) Delete all of the product"?s runtime data files. This is everything beneath the "�\Server\GeoEventProcessor\data folder. This removes the ActiveMQ cache, other cached data, the generated Java bundles "� etc. used by GeoEvent Processor at runtime. If you delete these two system resources, and there are no files in: C:\Program Files\ArcGIS\Server\GeoEventProcessor\deploy ... ... when you start the GeoEvent Processors"? Windows service it should be as if you just installed the product. You will need to give the system some time (typically about 30 seconds, but generally not longer than a couple of minutes) to build the Java bundles and create the runtime files before you will be able to launch and log-in to the GeoEvent Processor Manager. Please let us know if this resolves the issue. - RJ ... View more

Ananth - Thank you for the sample TAIP / RVP data and references you sent. It appears that the SierraWireless mobile gateway configuration utility - the "ACE Manager" - allows an optional TAIP ID to be specified on its GPS page. We will see what we can do to to extend the sample TAIP conector to: 1) Determine if this parameter has been included in the broadcast data; 2) Place the TAIP ID, if found, into the DeviceId field of the GeoEvent as a String. I will follow-up with you as soon as possible. Thank you in advance for your patience. - RJ ... View more

Hello Ananth - Yes, looking at the TAIP0xF0 GeoEvent Definition, the DeviceId is being retrieved from the event payload by the adapter. In fact it is being used as the TRACK_ID. What output are you using to review the event data? Are you receiving the other fields (TimeStamp, Shape, Speed, Heading, Source, and Age)? - RJ ... View more

Hello Brian - The inbound connector being discussed in this thread - Receive Features on a REST endpoint - has a program name / identifier esri-receive-features-rest-in. You are correct, this input requires that an external party POST content to the GeoEvent Processor. The adapter being used by this inbound connector expects that Esri Feature JSON, not generic JSON, will be sent. If you wanted an external party to be able to POST generic JSON to the GeoEvent Processor you would use the Receive JSON on a REST endpoint inbound connector (which has a program name / identifier esri-receive-json-rest-in). You've indicated that you want to periodically poll an ArcGIS feature service to obtain features and process those as events. For this you would want to use the Poll an ArcGIS Server for Features inbound connector (which has a program name / identifier esri-in-poll-feature-service). This connector allows you to specify the registered ArcGIS Server connection, the services folder, the feature service or map service, and the layer from which features should be retrieved. You also specify the Refresh Interval (how often you want GeoEvent Processor to poll the service). When you say "... an ArcGIS server feature for updates, one that is not my own", I'm not sure if you mean another publisher's feature/map service running on your ArcGIS for Server ... or if you mean some external server. You may need to use the Poll an external website for JSON inbound connector if you are polling a site/server external to your organization. Be aware that this input expects generic JSON, not Esri Feature JSON, and you may have to build the Geometry using values returned in specific event fields. Hope this answers your question - RJ ... View more

Simon - Polling the feed you indicated:  [url=http://pipes.yahoo.com/pipes/pipe.run?_id=7892c39c1778e81c27aeb4a0ba265623&_render=json]http://pipes.yahoo.com/pipes/pipe.run?_id=...&_render=json[/url] it appears to me that all of the items event fields are being expressed as JSON strings, with the first item in the list advertising the expected field names. : : items: [ { Site: "Site", LastSampleTime: "Last Sample Time", RiverLevel: "River Level", FlowRate: "Flow Rate", RainfallIntensity: "Rainfall Intensity", WaterTemp: "Water Temperature", Conductivity: "Conductivity", description: null, title: null }, { Site: "210001-Singleton", LastSampleTime: "30/04/2014 05:57:56", RiverLevel: "0.652", FlowRate: "400.2", RainfallIntensity: " ", WaterTemp: " ", Conductivity: " ", description: null, title: null }, ... The GeoEvent Definition generated for me by the GeoEvent Processor input specifies that all fields are expected as String: [ATTACH=CONFIG]33454[/ATTACH] When I send the poll'd JSON to a GeoEvent Cache, I can review the event data as either Text or JSON by visiting the appropriate REST endpoint for the cache: localhost:6180/geoevent/rest/cache/cache-out?f=text localhost:6180/geoevent/rest/cache/cache-out?f=generic-json The GeoEventCache adapter used by the Publish GeoEvents on a REST endpoint appears to be handling the unicode string/character \u00a0 being reported when values are missing/unreported as part of the unicode extended character set. [ATTACH=CONFIG]33455[/ATTACH] The Text adapter used by the Publish text to a TCP Socket, on the other hand, appears to be converting the "non breaking space" character ... which in HTML is &# 160; ... to an ASCII extended character equivalent:  á. What you could do, to avoid having this unicode character being interpreted by different adapters, is edit the generated GeoEvent Definition to specify that the metric values are expected as type Double. The input will then attempt to cast the JSON string values it receives to Double, and set the field's value to null if the type cast fails. Might as well include the description and title event fields from the provided JSON, currently being reported as null strings, while you're at it: [ATTACH=CONFIG]33457[/ATTACH] Notice in the following illustration that in a "text" adaption of the event data, the null fields appear "empty", while in a JSON adaption of the event data the null fields are not reported. [ATTACH=CONFIG]33459[/ATTACH] I think this will better allow you to apply filter criteria, process events, and eventually send event data to a feature service. Better, in my opinion, to send "null" data as null than as a "non-breaking space" unicode character. - RJ ... View more

Hello Simon - I think the problem is with the Field Calculator (Regular Expression) processor's configuration. Looking at your screenshot, the Field Name has been specified as:  Site.  When using the "regular" Field Calculator processor, field names are expressed without decoration. When using the Field Calculator (Regular Expression) processor you need to enclose field names in curl-braces and prepend a '$' ... so your configuration needs to specify ${Site} rather than just Site. This is a common source of confusion. With the 10.2.2 product release the "regular" Field Calculator processor will accept Java String functions - some of which accept RegEx expressions. Hopefully this will reduce the need to use the Field Calculator (Regular Expression) processor ... and help eliminate the confusion in how the two processors expect event field names be specified. For example, if you are using 10.2.2 you could configure a "regular" Field Calculator processor with an expression like replaceAll(fieldName,'[-].*','') to identify and replace all characters following a literal '-' with an empty string. That would effectively trim SiteId-SiteName expression down to just the 6-digit SiteId.  (You could also use the substring() function to grab just the first six characters of the SiteId-SiteName expression ... something like substring(fieldName,0,6).) If you are using 10.2.1 you won't have support for Java String functions. In that case you'll have to stick with the Field Calculator (Regular Expression) processor, specify the field name ${Site}, use a RegEx pattern like ^[0-9][0-9]*, and either place the substring into a new field (allowing you to specify that it is an Integer or Long) ... or overwrite the existing Site field value with the substring as a string representation of the SiteId. ... View more