Common output issues and solutions

ArcGIS Velocity may not work properly if not configured correctly. Below are some of the common issues you may encounter in Velocity when writing features from a real-time analytic to various output types as well as recommended solutions. If you encounter an issue that's not addressed below, check Esri Community or contact Esri Technical Support.

Note:

For issues and solutions related to accessing the Velocity app, signing in, or creating and starting items, refer to troubleshooting Velocity.

Common issues when configuring a feature layer

The following are common issues and solutions when creating a new feature layer or adding features to an existing layer.

Errors when creating a new feature layer or adding features to an existing layer in a relational and/or spatiotemporal ArcGIS data store

Velocity can write to feature layers in a relational and spatiotemporal ArcGIS data store. Errors when writing to output feature layers can occur for several reasons. It is recommended that an ArcGIS Enterprise administrator follow these steps to verify if there is a relational and/or spatiotemporal data store configured with your Enterprise environment. If validation for a data store fails, check the ArcGIS Server logs for more details.

Learn more about troubleshooting an ArcGIS data store

The schema from a data source does not match the schema from the pipeline. The input schema has fields that do not exist in the destination schema

This message appears as an error on a feature layer (new) output if your schema has changed and your feature layer output was configured to keep existing features and schema each time the analytic is started.

This message appears as a warning on a feature layer (new) output if your schema has changed, yet your feature layer output was configured to replace existing features and the schema each time the analytic is started. This warning can be ignored if this is an intentional change.

This message is expected behavior. You can either edit the analytic to revert to the previous schema or configure a new feature layer output that replaces existing features and the schema each time the analytic is started.

The schema changes when keeping existing features and schema each time the analytic is started

When creating a feature layer output, you must decide whether to keep existing features and schema or replace the features and schema each time the analytic is started.

If you choose to keep existing features and the schema each time the analytic is started, the schema of the data sent to this output must remain the same. If you need to change the schema sent to this output, in the analytic, delete the feature layer (new) output and create an output.

A published service with the name 'yourOutputName' already exists with the organization. Service names must be unique across the organization. Use a different name

When creating a feature layer output, a unique name must be specified for the output layer. Feature layer (service) names must be unique across the organization since each feature layer exposes a REST endpoint service URL to access the layer.

You can encounter this message if you deleted a feature layer or a feature layer node and configured the feature layer (new) output again. If the real-time analytic has run or is running since the feature layer was deleted, the feature layer would have been re-created by the running analytic. Therefore, when you try to configure this new feature layer output with the same name, the name is flagged because it already exists.

To resolve this, stop the real-time analytic and delete the feature layer. Return to your analytic and re-create the feature layer (new) output with the desired name.

Learn more about how to delete an output layer from the layers page

A common issue when sending to Kafka

The following is a common issue and solution when configuring a Kafka output.

The Kafka broker or topic is inaccessible

To send output messages to Kafka, the destination Kafka broker and topic must be externally accessible on the internet for Velocity to communicate with it.

Common issues when sending to Email

The following are common issues and solutions when configuring an Email output.

The SMTP server is inaccessible

When configuring an Email output, you must provide the address of an SMTP server. Velocity sends the request to send an email to the SMTP server, however, the SMTP server actually sends the email.

To send an email request to an SMTP server, the SMTP server must be externally accessible on the internet for Velocity to communicate with it.

The SMTP server is enforcing rate limiting

If sending many output features to the Email output, your SMTP server can limit your message processing requests.

When configuring the Email output, you must provide an address to an SMTP server that is accessible to Velocity. Some SMTP servers and administrators may choose to limit how many emails can be sent per day by a single user.