Elija el plan adecuado
- Antes de empezar a crear una aplicación en AppCreator, es importante entender lo que la plataforma AppCreator puede ofrecer y los detalles de cada plan.
- Como regla general, lo ideal es tener al menos un 5-10% más de alcance que el requerido. Esto asegurará que su aplicación pueda escalar en caso de que haya un pico de actividad de los usuarios.
- Identifique quién va a utilizar la aplicación y diseñe de acuerdo con sus necesidades. Por ejemplo, puede elegir un plan de portal de clientes para satisfacer las necesidades de sus clientes, proveedores y socios.
Mejores prácticas de seguridad
Usuarios y permisos
- En la aplicación solo deben añadirse los usuarios necesarios y compartirse los módulos necesarios.
- Los usuarios o desarrolladores que ya no necesiten acceso a la aplicación deben ser eliminados.
- Cuando más de un usuario esté creando la aplicación, añada los usuarios necesarios como desarrolladores en lugar de compartir las credenciales de administrador.
- El acceso a la información de identificación personal (PII) y a los datos de la información de salud protegida electrónica (ePHI) sólo se pueden dar a los conjuntos de permisos necesarios.
- Los permisos para Exportar, Eliminar, Ver todo y Editar de forma masiva deben ser limitados.
- Los conjuntos de permisos que no son indispensables para los usuarios y clientes se pueden eliminar.
Formularios e informes
- Los campos que recopilan o contienen datos PII y ePHI deben estar encriptados.
- La información sensible se puede enmascarar en los informes siempre que sea posible.
- Se pueden añadir filtros y criterios a los informes para garantizar que sólo se muestre a los usuarios la información necesaria.
- Cualquier información sensible que se almacene puede ser eliminada cuando ya no sea necesaria.
- Los mensajes de confirmación se pueden asociar a botones de acción personalizados.
- No es aconsejable recopilar o almacenar información sensible como números de la seguridad social o contraseñas. Si se recopila, el propósito debe estar claramente indicado en el formulario.
- Es mejor evitar el almacenamiento de credenciales de la API en la aplicación.
- Se puede asociar texto de ayuda o información sobre herramientas a los campos para explicar el motivo de la recopilación de datos.
- Se pueden añadir campos de nota a los formularios para especificar a los usuarios la finalidad de la recopilación de datos.
- Es aconsejable desactivar los formularios publicados cuando el acceso público ya no sea necesario.
- Se puede utilizar una casilla de decisión para obtener el consentimiento para la recopilación de datos.
- Se debe utilizar la autenticación basada en OAuth siempre que sea posible al invocar las API.
- Cuando se recopila la dirección IP, es aconsejable informar a los usuarios de ello y obtener su consentimiento. La dirección IP también se puede cifrar.
- Las acciones en los informes, como Añadir, Eliminar y Duplicar, se deben revisar, y se pueden eliminar si no son necesarias.
- El historial de los cambios realizados en los registros también se puede controlar mediante la función de pista de auditoría.
Flujos de trabajo y scripts
- Se deben validar las entradas para los campos siempre que sea posible.
- Cualquier hipervínculo utilizado en la aplicación se debe verificar.
- Se debe revisar el contenido de las tareas de SMS y correo electrónico.
- La lógica de negocio, como las funciones y los flujos de trabajo programados, se pueden ejecutar dentro del propio constructor de flujos de trabajo antes de ser incorporados al flujo principal.
Páginas
- Se debe revisar el código HTML y JavaScript.
- Utilice comentarios siempre que sea posible.
- Para las páginas que funcionan en base a parámetros, asegúrese de incluir comprobaciones de nulidad para evitar que la página muestre errores o datos irrelevantes.
- Evite duplicar los estilos CSS.
Mejores prácticas de la aplicación
Prácticas generales
- Defina la estructura de la aplicación, identifique el modelo de datos (los campos, las relaciones, la codificación de los campos), y tenga en cuenta los puntos débiles del proceso actual antes de empezar a desarrollar la aplicación.
- Documente la estructura de la aplicación. Esto facilitará la implementación de cambios más adelante.
- Asigne nombres significativos a todos los componentes: formularios, campos, informes, flujos de trabajo, páginas, variables, funciones y conjuntos de permisos.
- Utilice campos de búsqueda para crear relaciones entre los formularios y evitar datos redundantes entre ellos.
- Establezca propiedades como valores obligatorios y no duplicados en los campos para mantener la integridad de los datos.
- Elimine los componentes que no son necesarios en la aplicación.
- Especifique el comportamiento de eliminación de los registros, es decir, lo que ocurrirá con los registros relacionados cuando se elimine un registro concreto. Por ejemplo, si se elimina un empleado, ¿qué ocurrirá con las tareas que tiene asignadas?
- Realice cambios en la aplicación en un entorno de pruebas y pruébelos antes de publicarlos.
- Utilice la función de copia de seguridad programada de la aplicación para crear copias de seguridad periódicas.
Mejores prácticas de Deluge
Deluge es el lenguaje de scripting integrado en AppCreator. Es fácil de aprender y viene con un entorno de desarrollo integrado que le permite arrastrar y soltar fragmentos de código de Deluge mientras codifica.
Prácticas generales
- Las sentencias de depuración, como "info", se pueden utilizar siempre que sea posible para eliminar errores.
- Evite el anidamiento excesivo de scripts y optimice los bucles.
- Utilice eficazmente la tarea de agregación de registros. Busque en todos los registros sólo cuando sea necesario.
- Utilice las funciones integradas siempre que sea posible, ya que están optimizadas para un mayor rendimiento.
- Las sentencias Try Catch se pueden utilizar para manejar las excepciones en el código.
- Las variables pueden tener nombres significativos.
- Utilice las variables del sistema como zoho.appUri y zoho.appName para que el nombre del enlace de la aplicación, o los cambios de nombre del propietario no afecten a su funcionalidad.
- Esto es especialmente útil para el script de Deluge utilizado dentro de las páginas HTML para incrustar componentes.
- Las funciones se pueden utilizar para crear bloques de código reutilizables a partir de código frecuentemente utilizado o duplicado.
- Se puede eliminar el código no deseado y comentado para mantener la base de código limpia para facilitar el mantenimiento.
- Se puede aplicar sangría a los scripts y se les pueden añadir comentarios para proporcionar una breve idea de la lógica y el propósito.
- Mantenga el código modular.
- Se puede utilizar el asistente de sintaxis para ayudar a configurar las tareas.
- El control de versiones también está disponible para hacer un seguimiento de las distintas versiones y cambios en el código.
- Cuando se hace uso de la tarea invokeURL Deluge para hacer llamadas a la API, la respuesta no se almacena ni se procesa en los datos que conserva AppCreator, lo que hace que Deluge esté a salvo de cualquier vulnerabilidad.
- Cualquier error en el scripting de Deluge sólo afectará a la lógica de la aplicación, y no causará ninguna vulnerabilidad.
- Los errores de sintaxis que surjan en Deluge se mostrarán cuando un usuario intente guardar el script. El código no se guardará ni se ejecutará hasta que se rectifique el error.
- Los errores lógicos que se produzcan debido a malas prácticas y errores de programación se deben localizar y corregir.
- Cualquier código de Deluge que se escriba se debe optimizar para asegurarse de que no se alcancen los límites de las sentencias de Deluge. Estos límites se han establecido para evitar el uso indebido accidental de los recursos.
- Para mejorar el rendimiento, utilice las funciones predefinidas de Deluge: equalsIgnoreCase, equals para comparar en lugar de "==".
Scripts que se deben evitar
A continuación se indican algunos scripts que se pueden evitar. Se proporcionan alternativas para ellos.
Ejemplo 1:
En lugar de comprobar el recuento desde la sentencia de búsqueda, puede utilizar directamente la colección de búsqueda dentro del bucle.
fetchInvoices = Invoice[Client == input.Client && Location.equalsIgnoreCase("Chennai") && Bill_Payment_Status == "Not Paid"];
if(fetchInvoices.count() > 0)
{
for each invoice in fetchInvoices
{
}
}
//------------------------------------------
//En su lugar, utilice el siguiente script
//------------------------------------------
fetchInvoices = Invoice[Client == input.Client && Location.equalsIgnoreCase("Chennai") && Bill_Payment_Status == "Not Paid"]{
}
if(fetchInvoices.count() > 0)
{
for each invoice in fetchInvoices
{
}
}
//------------------------------------------
//En su lugar, utilice el siguiente script
//------------------------------------------
fetchInvoices = Invoice[Client == input.Client && Location.equalsIgnoreCase("Chennai") && Bill_Payment_Status == "Not Paid"]{
}
Ejemplo 2:
Puede utilizar las funciones incorporadas para evitar los bucles.
paymentList=List();
for each invoice in PaymentAgainstInvoice[ID == rushPayment]
{
paymentList.add(invoice.ID);
}
//------------------------------------------
//En su lugar, utilice el siguiente script
//------------------------------------------
paymentList = PaymentAgainstInvoice[ID == rushPayment].ID.getAll();
for each invoice in PaymentAgainstInvoice[ID == rushPayment]
{
paymentList.add(invoice.ID);
}
//------------------------------------------
//En su lugar, utilice el siguiente script
//------------------------------------------
paymentList = PaymentAgainstInvoice[ID == rushPayment].ID.getAll();
Ejemplo 3:
Esta es otra forma de utilizar las funciones incorporadas para evitar los bucles.
fethcInvoice = Invoice[ID == input.invoiceId];
for each lineitmcount in fethcfrominv.Line_Items
{
contlines = contlines + 1;
}
//--------------------------------------------
//En su lugar, utilice el siguiente script
//------------------------------------------
count=fethcInvoice = Invoice[ID == input.invoiceId].count(ID);
for each lineitmcount in fethcfrominv.Line_Items
{
contlines = contlines + 1;
}
//--------------------------------------------
//En su lugar, utilice el siguiente script
//------------------------------------------
count=fethcInvoice = Invoice[ID == input.invoiceId].count(ID);
Ejemplo 4:
Este ejemplo de código muestra cómo evitar operaciones de actualización innecesarias.
billId = insert into Bill
[
Added_User=zoho.loginuser
Total_Price=Total_Price
Bill_Status=Bill_Status
];
fetchBill = Bill[ID == billId];
if(patient_Type == "Free")
{
fetchBill.Total_Price=0;
fetchBill.Bill_Status="Closed";
}
//--------------------------------------------
//En lugar de utilizar el código anterior, podemos realizar la comprobación antes de insertar los datos en el formulario de factura. Esto evitará la operación de actualización innecesaria
//--------------------------------------------
if(patient_Type == "Free")
{
Total_Price=0;
Bill_Status="Closed";
}
billId = insert into Bill
[
Added_User=zoho.loginuser
Total_Price=Total_Price
Bill_Status=Bill_Status
];
[
Added_User=zoho.loginuser
Total_Price=Total_Price
Bill_Status=Bill_Status
];
fetchBill = Bill[ID == billId];
if(patient_Type == "Free")
{
fetchBill.Total_Price=0;
fetchBill.Bill_Status="Closed";
}
//--------------------------------------------
//En lugar de utilizar el código anterior, podemos realizar la comprobación antes de insertar los datos en el formulario de factura. Esto evitará la operación de actualización innecesaria
//--------------------------------------------
if(patient_Type == "Free")
{
Total_Price=0;
Bill_Status="Closed";
}
billId = insert into Bill
[
Added_User=zoho.loginuser
Total_Price=Total_Price
Bill_Status=Bill_Status
];
Recursos
Mejores prácticas de la aplicación móvil
- Se pueden determinar y cambiar las acciones y eventos desencadenados, como seleccionar un registro, deslizar hacia la izquierda y hacia la derecha.
- Las columnas de la vista rápida y de la vista detallada se pueden configurar según el contexto de la aplicación.
- Se puede cargar un logotipo personalizado en las aplicaciones.
- Las aplicaciones pueden cambiar de marca y publicarse por separado, sin conexión, para los usuarios y clientes.