• Cosas

• Plantillas de cosa

• Definiciones de cosa

• Recursos

• Autenticadores

• Defina las convenciones de asignación de nombres para los servicios. Se deben tener en cuenta los siguientes puntos:

◦ Proporcione un nombre y una descripción lógicos y descriptivos para el servicio.

◦ Utilice una nomenclatura estándar en todos los servicios. Por ejemplo, anteponga al nombre del servicio como prefijo un verbo y una descripción del servicio. A continuación, se muestran algunos ejemplos de verbos:

◦ Evite nombres ambiguos.

◦ Evite nombres de servicio largos siempre que sea posible.

• Agrupe las propiedades y los servicios comunes en una única entidad, preferiblemente una definición de cosa.

• Siempre que sea posible, implemente servicios en definiciones de cosa.

• Diseñe servicios para diferentes capas, tales como una interfaz de usuario, lógica empresarial y recuperación de datos. Los servicios de diferentes capas tienen responsabilidades diferentes. En la siguiente imagen se proporciona un ejemplo de las responsabilidades de las distintas capas:

• Al escribir un servicio, intente reutilizar los fragmentos de código disponibles de la biblioteca de fragmentos de código de ThingWorx. Si no está seguro de cómo utilizar cualquiera de los fragmentos de código, pruébelos antes de utilizarlos en el servicio.

• Al crear el servicio con la salida definida en JSON, se debe tener en cuenta lo siguiente:

◦ Si las propiedades tienen valores como null o undefined, no se devuelven en el resultado.

◦ Si la propiedad es un objeto JSON y se define en null, se devuelve en el resultado.

• Si prevé que el servicio tardará mucho tiempo en completarse, asegúrese de que el usuario no pueda activar el servicio más de una vez al mismo tiempo.

• Si el servicio se basa en un activador de eventos de un mashup, utilice el evento ServiceInvokeCompleted para permitir el flujo de datos en una solución.

• Para renovar los datos de mashups, se recomienda utilizar un widget de renovación automática o el servicio GetProperties.

• Para las conversiones simples en tiempo de ejecución, se recomienda utilizar el widget de expresión en lugar de los servicios.

• Añada verificaciones al código para evitar la posibilidad de que el usuario final reciba un error.

• Si la solución se va a localizar y hay texto en los elementos de la interfaz de usuario que cambia de forma dinámica en función del resultado de los servicios, asegúrese de no codificar los valores de texto en los servicios que se mostrarán en el mashup. Esto se debe a que es necesario localizar el resultado de los servicios que devuelve el texto. De este modo, se facilita también el mantenimiento y la modificación del texto de la interfaz de usuario en el futuro.

• Durante la creación de servicios personalizados, decida qué usuarios o grupos de usuarios deben tener permisos para invocar este servicio. Para obtener más información, consulte Protección de las soluciones integradas en ThingWorx Platform mediante la visibilidad y los permisos.

• Un posible resultado de la ejecución de servicios puede ser la creación de entidades fantasma. Las entidades fantasma se crean de forma dinámica mediante código o creación de scripts, en lugar de ThingWorx Composer. La creación de entidades fantasma es una práctica incorrecta. Para obtener más información, consulte Ejemplo: Creación y borrado de entidades fantasma.

• La configuración del tiempo de espera de un script por defecto en ThingWorx Platform es de 30 segundos. Si un script tarda más tiempo en ejecutarse que el definido en la configuración por defecto, ThingWorx Platform termina la ejecución. El 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.

• Pruebe el servicio incrementalmente, cuando se cree. Utilice los mensajes del registrador de scripts, si procede.

• Al probar un servicio, verifique si hay mensajes de error en los registros. Esto es especialmente útil para los servicios de suscripciones. Los siguientes ficheros de registro son de utilidad:

◦ ErrorLog.log: se proporciona un seguimiento de pila detallado de los errores.

◦ ScriptErrorLog.log: se proporciona información sobre el contexto del servicio (número de línea de error de pila).

• Si el servicio se llama desde un mashup, se debe probar en Composer y en el mashup.

• Si se necesitan entradas de usuario para que el servicio se ejecute, se puede utilizar la función de validador.

• Utilice las herramientas de desarrollador disponibles en los exploradores para comprobar el resultado de un servicio. Es útil cuando se desea depurar una secuencia de servicios que se ejecuta en un mashup. En esta herramienta se muestran los resultados del servicio en el contexto de esa ejecución específica.

• Si desea buscar servicios, no se debe abrir la entidad en el modo de edición. Utilice el vínculo de vista previa situado a la izquierda del nombre de la entidad para abrirla en modo Visualización.

• Seguridad: para mejorar la seguridad, utilice las sustituciones de servicio con el fin de denegar permisos en servicios críticos disponibles en ThingWorx Platform.

• Actualizaciones: utilice prácticas de codificación correctas y no cree grandes servicios monolíticos.

• Patrones de simultaneidad: el motor de aplicaciones no ejecuta los servicios de cosa de ThingWorx de manera aislada. Por lo tanto, los cambios en la propiedad de modelo de cosa que se realicen en un servicio son visibles inmediatamente en todos los demás servicios que se ejecuten simultáneamente. Si dos servicios intentan escribir la misma propiedad al mismo tiempo, ambas escrituras se realizarán correctamente. El valor de la propiedad terminará en el último estado que se haya ejecutado, que puede ser diferente del orden en el que las escrituras se enviaron al servidor. De hecho, en general, el acceso simultáneo a la mayoría de los datos y recursos de ThingWorx Platform se comporta en el modo de "la última escritura gana". Los desarrolladores y arquitectos de aplicaciones deben tener en cuenta estos comportamientos al crear aplicaciones.