Servicios de cosa
Los servicios de cosa son funciones que una cosa puede realizar. Cada cosa puede tener uno o varios servicios. Es posible definir servicios en el nivel de definición de cosa, plantilla de cosa o cosa. Un ejemplo simple de servicio es una consulta escrita para una cosa de base de datos.
Hay varios métodos de implementación, o controladores, para los servicios en función de la plantilla que se utiliza. Los scripts, las consultas SQL y los comandos SQL son ejemplos de controladores. Es posible que haya controladores adicionales disponibles según la funcionalidad específica de una cosa, como cosas Edge.
La implementación específica de un servicio definido por el usuario se realiza mediante un script del servidor (actualmente a través de SQL o JavaScript). El servicio se puede invocar a través de un URL, una aplicación con capacidad de cliente de REST o por otro servicio en ThingWorx.
Al crear un nuevo servicio, se pueden definir propiedades de entrada y una salida. Las entradas y salidas pueden ser de cualquier tipo de datos estándar de ThingWorx. Cada servicio también puede tener definidos permisos individuales de tiempo de ejecución en la definición de servicio. No se requiere que un servicio tenga entradas o salidas, pero normalmente tiene una o ambas. Por ejemplo, si desea enviar una programación de entrega a un camión, la cosa Camión puede tener un servicio con una entrada denominada DeliverySchedule y un tipo de XML. El servicio puede tomar los datos entrantes y colocar una propiedad de cosa del camión en una tabla de datos.
Si desea enviar la salida directamente a un widget de mashup, se debe elegir una salida de tipo base INFOTABLE. Si se elige generar la salida de una infotable, se deberá seleccionar una definición de datos. La definición de datos indica a la aplicación las columnas y los tipos de datos que se devolverán para que se puedan representar los datos. Se puede elegir cualquier número de entradas en función de los requisitos. Por ejemplo, la salida puede ser una consulta SQL en una base de datos que devuelva datos a un mashup. El servicio forma parte automáticamente de la API de REST del servidor de aplicaciones de ThingWorx (igual que todas las definiciones dentro del modelo). Se puede utilizar el servicio a través de una llamada a REST desde otra aplicación o en un mashup.
Al llamar a un servicio, si la salida se define como infotable, se puede pedir el conjunto de resultados como HTML, JSON o XML mediante una llamada del URL y el parámetro Aceptar URL (para obtener más información, consulte API de REST). Debido a esta flexibilidad y a la capacidad de que el entorno de mashup pueda consumir con facilidad una infotable, se recomienda utilizar este formato como patrón de diseño por defecto. Las necesidades específicas, como una salida de esquema XML, se pueden tratar según sea necesario.
Una vez definida la interfaz de función de script, se puede implementar el servicio pulsando en la columna del controlador del servicio. Esta acción permite abrir el editor de implementación de servicios. En el editor de implementación, se elige el controlador (consulta SQL o script). La consulta SQL solo está disponible para una entidad de base de datos. La implementación de script es un motor de scripts Java del servidor.
Con la consulta SQL, se escribe una consulta con la sintaxis que se utiliza para la base de datos de origen. Se pueden utilizar las entradas del servicio como parámetros en la consulta, igual como se haría con sentencias preparadas. Si la propiedad de salida es una infotable, no es necesario manipular los resultados. El resultado de la consulta aparece en la infotable y está disponible como salida.
El controlador de script es una manera potente de utilizar todos los datos, las cosas y los servicios en el servidor para satisfacer las necesidades de la aplicación. Se pueden realizar cálculos y búsquedas, llamar a servicios o acceder a propiedades desde otras cosas del modelo. Cuando se seleccione el script como controlador, se presentarán al usuario varios asistentes de script. Es posible ver las entradas para el script, las propiedades, los servicios y los eventos de la cosa que se está editando actualmente, y dichas entradas se pueden pegar en la ventana de script con una doble pulsación. También es posible inspeccionar las propiedades, los servicios y los eventos de cualquier otra entidad del sistema. Es posible combinar todas las capacidades del modelo dentro del servicio.
* 
Si al script se llama desde una página Web o un URL, se ejecuta en el contexto del usuario conectado. Si el usuario no tiene acceso a los servicios, las propiedades o los eventos en tiempo de ejecución de una entidad del script, este puede fallar.
El editor de implementaciones de script también tiene asistentes de sintaxis y fragmentos de código para facilitar la creación de un script.
* 
Por defecto, la configuración del tiempo de espera de un script en ThingWorx Platform es de 30 segundos. Si un script tarda más tiempo en ejecutarse, la plataforma anula la ejecución. Un administrador de ThingWorx puede configurar el tiempo de espera del script en la sección de configuración básica del fichero platform-settings.json.
Servicios asíncronos
Los servicios asíncronos se crean y ejecutan en su propio subproceso. Los servicios asíncronos no pueden tener un valor devuelto porque cuando se ejecutan, el subproceso se crea y se ejecuta independientemente en la plataforma. Si se llama desde dentro de otro servicio, el servicio de llamada no esperará a que el servicio asíncrono se complete. Puede ser bastante útil para los servicios de larga ejecución, especialmente los de los temporizadores que actualizan la estructura de datos en segundo plano o realizan tareas de mantenimiento del sistema.
Si se elige el modo asíncrono en el editor Nuevo servicio, aparece la opción Poner llamadas en cola. Esta opción es para los servicios enlazados remotamente que ponen en cola las ejecuciones de servicio si la cosa remota no está conectada. ThingWorx pone en cola los intentos en la ejecución del servicio y luego los ejecuta por orden cuando la cosa remota se vuelve a conectar.
Estadísticas de los servicios
El subsistema de utilización recopila las métricas de los servicios JavaScript que se anulan debido a un tiempo de espera agotado. Para obtener información detallada, consulte Estadísticas de ejecución de script anulada debido a un tiempo de espera agotado .