Diseñar un proceso
Objetivo
Dibujar un proceso: las calles que atraviesa, los pasos de cada una y las conexiones entre ellos.
Abrir el diseñador
Desde Procesos, seleccione un proceso y elija Diseñar, o haga clic en la fila. El lienzo se abre dentro de la aplicación, con la ruta de navegación y la barra de título todavía encima.
Un proceso que nunca ha dibujado se abre con un diagrama inicial en lugar de un lienzo vacío: una calle, un inicio y un fin. Esa es la forma que tiene todo proceso, así que es la forma desde la que se empieza.
Las cuatro zonas
- La paleta, en el borde izquierdo: lo que puede agregar: una calle y los tipos de nodo.
- El esquema, a su lado: el proceso como árbol: la raíz, sus calles y los nodos de cada una. Seleccionar en el esquema selecciona en el lienzo, y a la inversa. Arrastre su borde derecho para ensancharlo.
- El lienzo, en el centro: el diagrama en sí.
- El panel de propiedades, a la derecha: todo lo relativo a lo que esté seleccionado.
Calles: quién hace el trabajo
Agregue una calle desde la paleta, o arrastre una al lienzo. Póngale el nombre del rol, no de la persona —«Responsable», no un nombre propio—, porque un proceso sobrevive a quien ocupe el puesto este mes.
- Cambie el nombre de una calle haciendo doble clic en su cabecera.
- Cambie el tamaño de una arrastrando el límite que hay debajo. Las calles de debajo se desplazan hacia abajo con ella, y sus nodos también.
- Un nodo pertenece a la calle en la que está. Arrástrelo a otra calle y cambia de manos.
Establezca el rol de la calle, o sus pasos no irán a nadie
Llamar «Responsable» a una calle le dice a un lector quién hace el trabajo. No se lo dice al motor. Seleccione la calle y elija su Rol en el panel de propiedades: una búsqueda sobre los roles de seguridad que tiene este entorno, con un cuadro de búsqueda: empiece a escribir y la lista se reduce, por el nombre del rol o por su nombre lógico.
Antes era un cuadro en el que se escribía el nombre, lo que significaba que un error tipográfico producía una calle cuyo trabajo iba a un rol que no existe, y nada lo advertía hasta que una ejecución se detenía. Déjelo vacío y cada paso decide por sí mismo.
Cada tarea de usuario de esa calle va entonces a quien tenga ese rol, que es precisamente la razón por la que merece la pena dibujar una calle, y se establece una vez para la calle en lugar de en cada paso. Un paso con su propia expresión Asignado a tiene prioridad sobre ella.
Una calle sin Rol y pasos sin Asignado a son un proceso que se ejecuta y luego se detiene con «… no se pudo asignar a nadie». La tarea se crea de todos modos, para que un administrador la vea, pero no está en la lista de nadie.
Tienen que cumplirse dos cosas más antes de que un rol llegue a una persona: el rol tiene que existir (Roles, en el Centro de control de administración) y alguien tiene que tenerlo en una unidad (Roles de proceso, en la aplicación Organización). Consulte Configurar su organización.
Nodos: los pasos
| Tipo | Qué significa |
|---|---|
| Inicio | Donde empieza el proceso. Dibuje exactamente uno. |
| Fin | Donde termina. Puede haber varios: aprobado y rechazado son ambos finales. |
| Tarea | Un paso. El que más usará. |
| Bifurcación | Una decisión: una entrada, varias salidas. |
| División | Separar en caminos que se ejecutan todos. |
| Unión | Esperar a que esos caminos vuelvan a juntarse. |
| Temporizador | Esperar un tiempo, o hasta un momento. No se pide a nadie que haga nada. |
Una tarea tiene además un tipo de tarea, que se elige en el panel de propiedades: usuario, servicio, script, manual, envío, recepción, regla de negocio. Dibuja una pequeña insignia en el nodo, y es como un lector distingue de un vistazo «alguien rellena esto» de «la plataforma hace esto por sí sola».
Qué pasos esperan
Solo una tarea de Usuario hace que la ejecución espere a una persona. Cualquier otro tipo de tarea ejecuta su Al entrar y su Al salir y continúa directamente; su tipo está para quien lee el dibujo.
Cuando una ejecución tiene varias rutas
Tras una División, una ejecución está en varias rutas a la vez. Dos opciones deciden qué pasa cuando terminan.
- En una Unión, Continúa cuando: Han llegado todas las rutas (el valor por defecto), Llega la primera ruta o Ha llegado un número de rutas, con Cuántas rutas al lado. Cuenta las rutas que inició su División, no las conexiones dibujadas hacia ella. Una ruta que sigue en marcha cuando la Unión continúa se detiene, y su tarea abierta se retira.
- En un Fin, Cuando una ruta llega a él: Terminar esta ruta (por defecto: la ejecución termina cuando no queda otra ruta en marcha) o Terminar toda la ejecución, que detiene las demás rutas. La segunda es el final para «rechazado, detenerlo todo».
El título y el nombre de un paso
Todo paso tiene ambos, y cumplen funciones distintas: es el mismo par que el nombre para mostrar y el nombre lógico de una tabla.
- Título es lo que se lee en el cuadro del lienzo. Escríbalo para un lector, en el idioma en que trabaje, y cámbielo cuando quiera.
- Nombre es aquello con lo que el código, el historial de ejecución y otro proceso llaman al paso. Son letras minúsculas, dígitos y guiones bajos, y es obligatorio.
Normalmente no se escribe el nombre. Se rellena a partir del título mientras escribe
—«Approve Leave» se convierte en approveleave— y deja de seguirlo en cuanto usted lo edita,
así que un nombre que usted eligió nunca se sobrescribe. Vacíe el cuadro para recuperar la
sugerencia.
Dos pasos no pueden compartir un nombre. Si un título deriva uno que ya está ocupado, el recién
llegado recibe _2; el paso que lo tenía lo conserva, porque cambiarle el nombre cambiaría aquello
a lo que hace referencia cada script que ya apunta a él.
Un título en persa o árabe no deriva ningún nombre, así que el paso recibe el nombre de su tipo:
task, task_2. Cámbielo por algo que reconozca en el historial de una ejecución.
Antes el nombre era opcional, así que un proceso dibujado anteriormente puede tener pasos sin nombre, o con un nombre en el antiguo estilo libre. Esos documentos ya no se aceptan.
Abra cada uno en el diseñador y guárdelo. Los nombres se rellenan a partir de los títulos al abrirlo, y guardar es todo lo que hay que hacer. Nada los convierte por usted, y un proceso que no haya vuelto a abrir se negará a guardarse la próxima vez que lo edite.
Conexiones
Elija Conectar en la paleta y arrastre de un nodo a otro. Las conexiones se trazan automáticamente: usted no dibuja las esquinas.
- Ponga una etiqueta a una conexión cuando la necesite. En las conexiones de salida de una bifurcación es lo que un lector toma por la decisión: Aprobado, Por encima del límite, Rechazado.
- Estilo del conector —curvo o en ángulo recto— está en la raíz del proceso y se aplica a todo el diagrama, porque un diagrama que mezcla los dos parece un error y no una elección.
Variables: lo que lleva el proceso
Seleccione la raíz del proceso en el esquema y agregue Variables: los valores que este proceso lleva de un paso al siguiente. Cada una tiene un nombre y un tipo (texto, número, sí/no, fecha).
El nombre es lo que escribe un script: getVariable("total"). Cambiar el nombre de una
variable no reescribe los scripts que la nombran, así que trate el nombre como aquello que está
nombrando, no como una etiqueta que puede cambiar libremente. Una variable a la que todavía no ha
puesto nombre simplemente no se ofrece en ningún sitio.
Formularios de decisión: lo que una persona rellena para terminar un paso
Un formulario de decisión es el formulario breve que alguien rellena para completar una tarea de usuario, junto con los resultados: los botones que la terminan. No es un formulario basado en modelo sobre una tabla: pertenece al proceso, viaja dentro del documento del proceso y solo pregunta lo que la decisión necesita.
Seleccione la raíz del proceso en el esquema —que es donde se abre el diseñador— y verá Formularios de decisión debajo de Variables, porque un formulario de decisión pertenece al proceso y no a un paso concreto: varios pasos pueden mostrar el mismo.
Cada formulario de decisión tiene:
- Un nombre de formulario de decisión, que es como una tarea apunta a él, y un encabezado, que es lo que ve la persona que lo lee.
- Campos: un nombre de campo, una etiqueta y un tipo de datos. Son los tipos de campo propios de la plataforma, así que un formulario de decisión recibe los mismos selectores de fecha, calendarios y listas de opciones que un formulario de registro.
- Resultados: una fila por botón. El texto del botón es lo que pone en él, el estilo es su aspecto (normal, principal, destructivo), y Requiere un comentario hace que ese único botón exija una respuesta en el primer campo multilínea del formulario de decisión. Actívelo en un rechazo y déjelo desactivado en una aprobación: esa es la diferencia para la que existe el ajuste.
Después seleccione una tarea de usuario y elija su Formulario de decisión en la lista.
Una tarea sin formulario de decisión se completa igualmente, pero la persona no tiene manera de decir nada sobre ella. Un proceso cuyos pasos humanos no preguntan nada suele ser un proceso cuyo diseño aún no se ha terminado.
Qué consultan mientras deciden
Debajo del formulario de decisión, Qué consultan elige qué ocupa la zona principal mientras la persona decide: nada, el formulario de un registro, una lista, un informe o una pantalla. Elija uno y aparece el resto de la sección.
| Campo | Para qué sirve |
|---|---|
| Aplicación | Dentro de qué aplicación se abre. Déjelo en blanco y se abre en una aplicación que tenga aquello de lo que trata el paso: la aplicación en la que está la persona, si lo tiene, o si no una que participe en procesos de negocio. Es lo que permite que un proceso funcione después de importarlo en otro sitio. |
| Tabla / Informe / Pantalla | De qué trata el paso. Cuál de los tres aparece depende de lo que haya elegido arriba. |
| Qué formulario / Qué vista | Un formulario o una vista con nombre en lugar del predeterminado de la tabla. En blanco se usa el predeterminado. |
| Abierto | De solo lectura, o para editar. Solo lectura es la respuesta habitual —alguien lee para decidir— y la edición se ejecuta con los permisos propios del registro: una tarea no concede ningún acceso por sí misma. |
Cada uno de ellos es una lista desplegable de lo que este entorno tiene realmente. Antes eran cuadros en los que se escribía un nombre lógico, y un nombre escrito a mano solo puede escribirse mal, lo que aparece como «el paso no abre nada», semanas después, delante de la persona para la que se construyó el proceso.
Sobre qué registro se abre no está en esta lista: es una expresión, así que está en Código
con las demás. Normalmente getRecordRef("request"): el registro del que trata esta ejecución.
Parámetros: qué más se le dice al paso
El registro responde a cuál, y en un formulario suele ser toda la pregunta. No lo es en ningún otro sitio: un informe quiere el periodo que cubre, una pantalla quiere el importe que se aprueba y quién lo planteó. Esos valores están en esta ejecución, no en el artefacto.
Seleccione Agregar parámetro, dele el nombre que espera el informe o la pantalla, y su valor
aparece como una fila en Código, porque un valor es una expresión sobre las variables del
proceso y el estado de esta ejecución: getVariable("month"), instanceStartedBy().
Los nombres son como el artefacto encuentra un valor, así que dos parámetros no pueden compartir uno, y un parámetro sin nombre se descarta al guardar el proceso.
Resultados: qué decisión toma una conexión
Una tarea de usuario termina cuando alguien pulsa uno de los resultados de su formulario de decisión, y cada resultado envía el proceso por un camino distinto. Seleccione una conexión que salga de una tarea de usuario y establezca Se toma cuando: una lista desplegable de los resultados del formulario de decisión de esa tarea.
Eso es lo que hace que Aprobar o rechazar sea un solo paso en lugar de una tarea seguida de una bifurcación que vuelve a preguntar lo que la persona ya decidió.
- Solo se ofrece donde la tarea muestra un formulario de decisión con resultados. En otros sitios no hay nada entre lo que elegir.
- Un formulario de decisión con un resultado no necesita nada de esto: un botón, una salida.
- Con varios, cada uno necesita su propia conexión. El panel Problemas lo advierte: notifica un resultado que ninguna conexión toma, dos conexiones que reclaman el mismo, y una conexión que nombra un resultado que el formulario de decisión ya no ofrece, que es lo que ocurre cuando edita un formulario de decisión que también muestra otra tarea.
Llamar a otro proceso
Establezca el Tipo de una tarea en Llamar a proceso y elija el Proceso que se ejecuta. La idea es que este paso espere a que ese proceso termine y después continúe, pero el motor aún no lo ejecuta. La elección se guarda y el panel de problemas comprueba que haya uno elegido; al ejecutarse, el paso ejecuta su Al entrar y Al salir y continúa directamente sin iniciar el otro proceso, como cualquier paso que no es una tarea de usuario.
Úselo cuando varios procesos necesitan el mismo trabajo: una aprobación, una comprobación de crédito. Un proceso llamado tres veces sigue siendo una sola cosa que cambiar; tres copias de él discrepan en menos de un año.
El selector enumera los demás procesos de este entorno. Un proceso no puede llamarse a sí mismo.
Condiciones: por dónde va una bifurcación
Seleccione una conexión que salga de una bifurcación y abra su Condición en Código: una
expresión que decide si el flujo toma esa conexión. getVariable("approved") en un lado,
!getVariable("approved") en el otro.
Se ofrece en las conexiones de una bifurcación y en ningún otro sitio. Una tarea tiene una sola salida, así que una condición ahí sería una pregunta con una sola respuesta.
Una condición solo puede leer. Decide una ruta, y el motor puede preguntarle más de una vez, así que una condición que cambiara algo haría que el proceso dependiera de cuántas veces se le hubiera preguntado; el editor no le ofrece las palabras para hacerlo.
A quién va una tarea
Una tarea de usuario tiene una fila Asignado a en Código: una expresión que responde a quién debe hacerla.
| Quiere | Escriba |
|---|---|
| Quien tenga un rol | role("Manager") |
| Una persona concreta | user("a.khan") |
| Un equipo | team("Finance") |
| Quien inició el proceso | instanceStartedBy() |
Es una expresión y no un selector a propósito: las asignaciones que merece la pena escribir son las que un selector no puede expresar: el aprobador para el importe de una variable, el responsable de quien lo planteó.
Solo una tarea de usuario la tiene. Una tarea de servicio la hace la plataforma, así que no hay nadie a quien dársela.
Un paso sin expresión recurre al rol de su calle, que es el caso habitual: escriba la expresión solo donde un paso se aparta del resto de la calle.
Esperar, e ir con retraso
Un temporizador: esperar al reloj
Dibuje un Temporizador donde el proceso deba simplemente esperar. No se pide a nadie que haga nada: la ejecución se detiene ahí y continúa por sí sola.
Establezca Se dispara en Tras un tiempo y rellene Esperar: un número y una unidad elegida a su lado: 3 días, 4 horas, 90 minutos.
Un temporizador sin duración no espera: detiene la ejecución. Es el único ajuste de un proceso que no tiene un comportamiento predeterminado sensato detrás: dispararse de inmediato convertiría sin avisar una espera en ninguna espera, así que la ruta se detiene y el historial de la ejecución dice «… no indica cuándo se dispara». Si un temporizador que dibujó nunca se dispara, es lo primero que debe comprobar.
Los meses y los años no se ofrecen, a propósito. Un mes tiene 28 días en febrero y 31 en marzo, así que una espera escrita así significaría un número distinto de horas según cuándo empezara. Pida 30 días.
La duración se guarda como una duración ISO-8601 —P3D, PT4H, PT90M—, que es lo que lee el
motor y lo que tiene que decir un proceso escrito a mano o generado por una IA. Usted nunca la
escribe; el número y la unidad son todo el campo. Una duración escrita a mano en dos unidades
(PT4H30M) se abre como la misma duración en una sola (270 minutos).
Elija en cambio En un momento que responde el código cuando el momento depende de los datos: la fecha del registro, una variable que alguien rellenó. Después escriba la expresión en Código; puede responder con un momento o con una duración.
Un plazo: para cuándo debe estar hecho un paso
Seleccione una tarea de usuario y rellene Vence en: el mismo par de número y unidad que usa el temporizador. El reloj empieza en el momento en que la tarea aparece en la lista de alguien —no cuando la abre—, así que una tarea planteada el viernes por la tarde no gana en silencio el fin de semana.
La persona ve Vence … debajo de la tarea en su lista, y una vez pasado el momento se vuelve roja y dice Venció …. Al lado, En espera indica cuánto tiempo lleva ahí la tarea.
Cuando se retrasa indica qué hace el proceso al respecto:
| Opción | Qué ocurre |
|---|---|
| Marcarla como retrasada | Nada se mueve. La tarea aparece visiblemente retrasada en la lista, y el historial de la ejecución lo registra. |
| Ofrecerla también hacia arriba | Se le ofrece también a quien indique la escalación de la calle. La persona que ya la tenía la conserva: una persona más puede actuar, y no se le quita nada a alguien que quizá esté a punto de terminar. |
| Decidirla automáticamente | El proceso pulsa por ellos uno de los botones propios de la tarea. Elija cuál en Decidirla como. |
Decidirla automáticamente usa los resultados propios del paso, así que el diagrama ya muestra adónde va después el proceso: no hay una segunda salida invisible del paso. «Si nadie aprueba en tres días, trátela como rechazada» se escribe eligiendo Decidirla automáticamente y después Rechazar.
Deje Vence en vacío para un paso sin plazo, que son la mayoría; vaciar el número es lo que quita un plazo.
Mientras construye, establezca las duraciones en uno o dos minutos, publique e inicie una ejecución:
la escalación, la espera y la decisión automática ocurren mientras mira el historial de la
ejecución. Así viene configurado bpms-deadlines-and-timers, y es lo único poco
realista de ese ejemplo.
Código: lo que se ejecuta y lo que se calcula
Seleccione una tarea y obtendrá su lista de Código: todo lo de ese paso que está escrito en BS Lang. Seleccionar cualquier fila abre la página de código.
Los cuatro primeros son los momentos a los que puede reaccionar:
| Espacio | Cuándo se ejecuta |
|---|---|
| Al entrar | El proceso llega a este paso. |
| Al asignar | La tarea tiene a alguien: solo tareas de usuario. |
| Al completar | Esa persona la marca como hecha: solo tareas de usuario. |
| Al salir | El proceso sale de este paso, vaya por donde vaya. |
La raíz del proceso tiene tres propios, con la misma forma: Al iniciar, Al completar y Al cancelar. Al iniciar es donde se da a una variable su primer valor.
Debajo de ellos, en una tarea de usuario, están las cosas que calcula en lugar de ejecutar: Asignado a, Registro y una fila por parámetro, con el nombre del parámetro. Están en la misma lista porque son el mismo tipo de cosa —un fragmento de BS Lang que pertenece a este paso— y una sola lista es un solo lugar donde buscar «qué ejecuta este paso».
La lista indica qué filas ya tienen algo escrito, para que vea de un vistazo dónde está el trabajo.
Una bifurcación tiene Al entrar y Al salir, y ningún espacio que elija una ruta.
- Al entrar se ejecuta en cuanto llega el proceso, antes de preguntar ninguna condición. Es donde una bifurcación hace sus cálculos: calcule la respuesta una vez, póngala en una variable y deje que cada condición la lea. Seis tramos de un importe significan entonces seis condiciones cortas en lugar de seis copias de la suma.
- Al salir se ejecuta una vez elegida una ruta. No se ejecuta cuando ninguna condición fue verdadera: no se salió por ningún sitio, así que no hubo salida.
- La decisión sigue en las conexiones. A propósito, no hay código que elija una salida: un diagrama cuya bifurcación se decide en un sitio que no se ve es un diagrama que miente sobre lo que hace el proceso.
La página de código
Ocupa el editor y lleva la lista de espacios en su lateral, así que cambiar entre los momentos de
una tarea es un solo clic. El ojo de su cabecera enumera todo lo que se puede llamar desde ese
espacio, que no es lo mismo en todas partes: una condición y un Asignado a solo pueden leer, un
controlador puede cambiar cosas, y solo a Asignado a se le ofrecen user(), role() y
team().
No hay Guardar en la página de código. Guardar en la barra de título es el único, y guarda el proceso completo.
Guardar un script no lo ejecuta. Las variables, las condiciones, las asignaciones y los scripts se guardan con el diseño y se comprueban mientras los escribe; se ejecutan cuando el proceso está publicado y empieza una ejecución.
Problemas: lo que todavía falta
En la esquina del lienzo hay una barra que indica cuántos problemas tiene el proceso. Ábrala para ver la lista; seleccione una línea y el diseñador le lleva a aquello de lo que trata: el nodo, la conexión o la raíz del proceso.
Comprueba lo que el motor exigirá:
- exactamente un Inicio, y al menos un Fin;
- ninguna conexión entra en un Inicio ni sale de un Fin, porque una ejecución empieza en uno y termina en el otro, así que nunca se tomaría;
- ningún paso al que el flujo no pueda llegar nunca, y ninguno del que no pueda salir nunca;
- una condición en cada conexión que sale de una bifurcación, y al menos dos salidas de una;
- al menos dos salidas de una división y dos entradas a una unión, y el mismo número de cada una;
- cada variable que nombra un script está declarada, y cada fila de variable tiene nombre;
- cada script se analiza correctamente.
Nada de esto le impide seguir. Un proceso a medio dibujar notifica una página de problemas y se guarda perfectamente; para eso se dibuja. La lista es cómo averigua lo que queda, y es la misma lista que aplicará la plataforma cuando un proceso se publique para ejecutarse.
Una nota sobre dos de ellos. El panel indica si un script se analiza correctamente; si puede llamar a un nombre concreto es asunto del editor de código, que lo subraya mientras escribe según lo que ese espacio puede ver. Y las divisiones y uniones se cuentan, no se emparejan una a una: un proceso que se divide más veces de las que se une tiene un camino todavía en marcha cuando debería haber terminado, que casi siempre es el error.
Organizar automáticamente
Vista → Organizar automáticamente ordena el diagrama de izquierda a derecha, en el orden del flujo, manteniendo cada nodo en su propia calle. Mueve los nodos en horizontal y vuelve a trazar las conexiones; nunca pasa trabajo de una persona a otra.
Generar con IA
Generar con IA describe un proceso con palabras y lo dibuja. Lo que vuelve se valida antes de llegar al lienzo, exactamente igual que un archivo importado, así que un diagrama generado que no se sostiene se rechaza en lugar de dibujarse.
Se corrige a sí mismo antes de rendirse. Cuando lo que vuelve no se sostiene, la plataforma se lo devuelve directamente al modelo con el problema indicado, en lugar de pedirle a usted que corrija un error de esquema que nunca escribió. Lo intenta hasta tres veces, y mientras tanto el botón dice Corrigiendo… intento 2 de 3. Solo se le muestra un fallo después de haber intentado corregirlo, y lo que se le muestra entonces es lo último que estaba mal.
Sustituye lo que hay en el lienzo, y no guarda. Revíselo antes de pulsar Guardar.
Usted describe el proceso, y nada más. Qué modelo de IA responde lo configura una sola vez para toda la plataforma un administrador: no hay clave que pegar ni proveedor que elegir, y nada de lo que escriba aquí va a ningún sitio salvo a ese único modelo.
Si no hay ninguna IA conectada, Generar lo dice. Un administrador del inquilino la conecta una vez, en Configuración → IA, para toda la organización. No es algo que un creador active.
Guardar
Guardar, en la barra de título, escribe el proceso. Es el único Guardar: el diseño forma parte del componente, así que no hay ningún archivo que mantener sincronizado con él ni nada que recordar exportar.
Salir con cambios sin guardar pregunta antes: desde Cerrar, desde el carril de navegación y desde el propio botón Atrás del navegador.
Publicar: guardar no es entregar
Guardar conserva su trabajo. Publicar cambia lo que se ejecuta. Son dos botones porque son dos decisiones, y la separación existe por una razón: un proceso que ya está en marcha no debe cambiar bajo los pies de quienes lo ejecutan. Sin ella, corregir una errata a las cuatro de la tarde reescribiría el proceso que seguía cada instancia en curso, incluidos los pasos por los que ya habían pasado.
Así que el motor lee solo lo que usted ha publicado, y una publicación es una copia numerada y congelada del dibujo tal como estaba en ese momento.
La línea bajo el título indica en cuál de los tres estados está:
| Dice | Significa |
|---|---|
| Aún no publicado | Nada está ejecutando este proceso. |
| Se está ejecutando la versión 3, y coincide con lo que ve | Está viendo lo que está activo. |
| Se está ejecutando la versión 3. Tiene cambios sin publicar | Sus ediciones guardadas no están activas todavía. |
Seleccione Publicar y el borrador se convierte en la versión siguiente. Si tiene ediciones sin guardar, las guarda primero, porque publicar lo que hay en pantalla es lo que significa la palabra.
Algunas cosas que conviene saber:
- Publicar un proceso sin cambios se rechaza. Si nada ha cambiado desde la última publicación no hay nada que publicar, y un historial lleno de versiones idénticas es uno que nadie puede leer.
- No hay forma de despublicar. Una versión que alguien puede estar ejecutando no es algo que se deba eliminar. Si quiere volver atrás, ponga el dibujo anterior en el lienzo y publíquelo: el historial queda intacto, que es lo que hace que valga la pena tenerlo.
- Las instancias conservan la versión con la que empezaron. Algo que empezó con la versión 2 termina con la versión 2, publique usted lo que publique mientras se ejecuta.
Publicar no inicia nada. Decide qué se ejecuta la próxima vez que empiece el proceso, y las ejecuciones que ya están en marcha conservan la versión con la que empezaron.
Publicar espera a que la lista de problemas esté vacía. Mientras la esquina del lienzo muestre algo, el botón no está disponible, y al dejar el puntero encima dice por qué. Un proceso con problemas no se ejecutaría; antes, publicarlo guardaba primero el dibujo y después se rechazaba.
Importar y exportar
Exportar JSON descarga el diseño como un archivo .bpms.json: lo que hay en el lienzo
ahora, incluidas las ediciones sin guardar, porque el archivo sirve para llevar un diseño a otro
sitio, y exportar la versión de la semana pasada mientras mira la de esta semana es el tipo de
sorpresa que solo se descubre al otro lado.
Importar JSON vuelve a cargar uno. Sustituye lo dibujado y no guarda, así que una importación que resulta ser el archivo equivocado se deshace saliendo de la pantalla sin guardar.
El archivo se comprueba antes de cargarse: la versión, las calles, los nodos, y que cada conexión una realmente dos nodos que existen. Un archivo que no supera la comprobación indica qué identificador estaba mal.
Una vez que un proceso viaja en su solución, importar y exportar sirven para mover un diseño entre entornos a mano: una comodidad, no la forma de promover el trabajo. Esa es la solución.
Exportar una imagen
Exportar → Imagen (PNG) e Imagen (SVG) dibujan el diagrama tal como se ve: para un documento, una diapositiva o una pared. Ninguna de las dos es el proceso: no se pueden volver a importar.
Solución de problemas
-
Mi variable no aparece en las sugerencias del editor. — una variable sin nombre no se ofrece en ningún sitio. Dele un nombre a la fila y salga del campo para que el nombre se confirme.
-
No encuentro
setVariableen una condición. — una condición solo puede leer; consulte más arriba. Ponga el cambio en el script de una tarea. -
Un script que escribí en una tarea ha desaparecido. — cambiar el tipo de una tarea cambia los momentos que tiene. Cambie una tarea de usuario a tarea de servicio y Al asignar y Al completar dejan de ofrecerse, y a un diseño importado con ellos se le quitan.
-
«Ese archivo no es un JSON válido, así que no se pudo importar.» — el archivo está truncado o no es un diseño en absoluto.
-
«Ese archivo no es un diseño de proceso válido: …» — el detalle indica el identificador que está mal: un nodo en una calle que no está en el archivo, una conexión a un nodo que no existe.
-
Guardar dice que el diseño no es válido. — antes de guardar se ejecuta la misma comprobación. Corrija el nodo o la conexión que indica; el diagrama de la pantalla no se pierde.
-
Un nodo saltó al abrir el proceso. — un nodo que estaba fuera de su calle se devuelve a ella al abrir. La calle de un nodo es quién hace el trabajo, así que nunca se permite que las dos cosas discrepen.
-
Organizar automáticamente no hizo nada. — organiza según el flujo, así que necesita conexiones. Un diagrama de nodos sin conectar no tiene ningún orden en el que organizarse.
-
El panel de problemas dice que un paso «no lleva a ningún sitio». — desde él no se puede llegar a ningún Fin. Conéctelo hacia delante, o conéctelo con algo que ya llegue a uno.
-
Dice que mi script no se analiza, y en el editor de código parecía bien. — el panel comprueba todos los scripts del proceso, incluidos los que no está mirando. Seleccione la línea para ir al nodo y después abra el espacio que indica.
-
«No hay ningún proveedor de IA configurado. Abra Configuración → IA para conectar uno.» — la organización todavía no tiene conexión con una IA. Un administrador del inquilino la conecta una vez, en Configuración → IA, para todos.
-
«La IA respondió sin ningún diseño.» — el modelo contestó con texto en lugar de un proceso. Describa las calles y los pasos con más sencillez y vuelva a generar; no se pierde nada del lienzo.