Arbetsflöden för publicering/utcheckning

Arbetsflöden börjar påverka din verksamhet när du har publicerat dem. Tills du har publicerat ett giltigt arbetsflöde förblir det du designar ett fungerande utkast:

Innan ESM tillåter att ett arbetsflöde tas i aktiv drift, kommer det att validera om arbetsflödesdesignen innehåller några större fel, såsom saknade villkorssatser i villkorsaktiviteter. Element med felaktiga konfigurationer markeras med röda kanter på redigerarens arbetsyta tills konfigurationen är giltig.

När ett arbetsflöde har publicerats i aktiv tjänst kommer alla nya inkommande ärenden att utlösa körningen av arbetsflödet om urvalskriterierna är uppfyllda.

Om du efter att ha publicerat ett arbetsflöde märker att det inte fungerar som förväntat, eller om du vill ta bort det, kan du ta bort arbetsflödet från aktiv tjänst genom att checka ut det från aktiv tjänst. Om du gör det återställs arbetsutkastet till den arbetsflödesdefinition du checkade ut. Alla pågående problem som har hanterats av det utcheckade arbetsflödet förblir aktiva och ESM kommer att försöka slutföra dem enligt den utcheckade arbetsflödesdefinitionen. Du måste manuellt avsluta eventuella problem om de inte slutförs av sig själva. Alla nya problem för mallen kommer inte längre att hanteras av det utcheckade arbetsflödet utan måste bearbetas manuellt eller genom ett ersättningsarbetsflöde.

Arbetsflödets livscykel

ESM håller reda på flera versioner av ett och samma arbetsflöde:

• Ett fungerande utkast som är den senaste versionen du har sparat.
• Det senast publicerade arbetsflödet med vilket nyskapade eller uppdaterade datakort kommer att bearbetas om de uppfyller urvalskriterierna för arbetsflödet.
• Alla tidigare publicerade versioner av arbetsflödeskonfigurationer så länge det fortfarande finns datakort som bearbetas.

När du öppnar ett arbetsflöde i arbetsflödesredigeraren arbetar du som standard alltid med den utkastade versionen. Om du väljer att hämta ett arbetsflöde från den aktiva tjänsten (dvs. ångra publiceringsåtgärden) återställs den utkastade versionen av arbetsflödet till den arbetsflödesversion du just har hämtat.

Ändringar i arbetsutkastet sparas inte automatiskt i databasen. Du bör spara ändringarna eller ignorera dem innan du gör något annat i ESM.

Du måste alltid publicera dina ändringar för att aktivera dem för nya eller uppdaterade datakort. När du publicerar ett arbetsflöde i en aktiv tjänst sparas den versionen automatiskt som ett nytt arbetsutkast.

Du kan ta bort arbetsflöden från ESM genom att välja knappen Ta bort. Du kan dock bara ta bort arbetsflöden som inte har några öppna ärenden. För att ta bort ett arbetsflöde måste ärenden antingen ha gått igenom hela arbetsflödessekvensen eller ha avslutats av en ESM-användare. Du kan inte manuellt ta bort gamla versioner av arbetsflödeskonfigurationer. De kommer att tas bort av systemet när det sista datakortet har bearbetats.

Att checka ut ett arbetsflöde räcker inte för att aktivera borttagning eftersom det fortfarande kan finnas problem som aktivt bearbetas med arbetsflödet. ESM kommer alltid att validera om det fortfarande finns några problem innan borttagning av arbetsflödet tillåts.

Exportera/importera arbetsflöden

Alla arbetsflöden kan exporteras till din arbetsstation och sedan importeras igen, till exempel till ett produktionssystem. För att exportera och importera arbetsflöden, välj motsvarande åtgärd från rullgardinsmenyn Arbetsflöde. Kom ihåg att även exportera och importera motsvarande mallar.

Export exporterar den senast publicerade versionen av det valda arbetsflödet. Endast om det inte finns någon publicerad version exporteras arbetsutkastet.

Exportera/importera arbetsflödesnoder

Det är möjligt att exportera en enskild arbetsflödesnod och återanvända den i ett annat arbetsflöde i en annan mall. För att exportera en arbetsflödesnod, välj först motsvarande arbetsflödesnod och välj sedan "Exportera arbetsflödesnod" från rullgardinsmenyn Arbetsflöde. Arbetsflödesnoden laddas sedan ner till din dator.

För att importera en arbetsflödesnod måste du först välja det arbetsflöde som du vill importera arbetsflödesnoden till. Attribut och attributvärden som inte har matchande objekt i målmallen kommer att ersättas med tomma fält efter importen. Den vanliga arbetsflödesvalideringen identifierar potentiella korrigeringar som måste göras i den importerade arbetsflödesnoden.

Verifiera arbetsflödesstatus för ett problem

Arbetsflödesmotorn kommer att underhålla arbetsflödets status för varje ärende. Arbetsflödets status kan ses i datakortvyn för själva ärendet. Möjliga tillstånd är: Körs, Avslutad, Fel eller Avbruten. Arbetsflödets status är ett systemvärde men kan göras synlig genom att tilldela WorkflowStatusHandler till ett attribut.

Alla användare kan avbryta arbetsflödeskörningen manuellt genom att klicka på arbetsflödesstatusindikatorn.

Granska arbetsflödeskonfigurationer

ESM kommer automatiskt att hålla reda på ändringar i arbetsflödena i den systemomfattande konfigurationsloggen. Skapandet av nya arbetsflöden, borttagning, publicering, all redigering och utcheckning loggas med tidsstämpel och användar-ID. Du kan granska eventuella ändringar i arbetsflödena från konfigurationsloggfilen.

Loggning av arbetsflödeskörning

Loggposter genereras för varje arbetsflödeskörning för att underlätta administration och felsökning. Dessa poster sparas i filen workflow.log. För att ladda ner loggfilen, gå till Administration > Underhåll > Loggar > Ladda ner loggar . Nedan visas ett exempel på hur körningen av en arbetsflödesnod registreras i loggarna. Avsnitten som är markerade med fetstil representerar viktiga aspekter av loggen. För enkelhets skull är loggutdraget numrerat i tur och ordning. Dessa nummer motsvarar de i den bifogade skärmdumpen av relevant arbetsflöde, som visas efter loggutdraget.

1. WorkflowLogger|INFO|2023-03-22 10:12:12,123|datacard {id: 123456789, name: Ticket name| EFE-123456, templateName: Agreement checklist} run workflow {id: 371441422, name: Checklist approval workflow NEW , templateId: 119733870, wrapperId: 366102831}
2. WorkflowLogger|INFO|2023-03-22 10:12:12,123|datacard {id: 123456789, name: Ticket name| EFE-123456, templateName: Agreement checklist} running StartpointNode {id: 371440955, name: Begin}
3. WorkflowLogger|INFO|2023-03-22 10:12:12,273|datacard {id: 123456789, name: Ticket name| EFE-123456, templateName: Agreement checklist} running ConditionNode {id: 371441271, name: LOB SMB escalation or risk amount 1,5m}
4. WorkflowLogger|INFO|2023-03-22 10:12:12,275|datacard {id: 123456789, name: Ticket name| EFE-123456, templateName: Agreement checklist} run then path:Then
5. WorkflowLogger|INFO|2023-03-22 10:12:12,430|datacard {id: 123456789, name: Ticket name| EFE-123456, templateName: Agreement checklist} running ApprovalNode {id: 371441119, name: LOB SMB Approval }
WorkflowLogger|INFO|2023-03-29 13:46:25,469|datacard {id: 123456789, name: Ticket name| EFE-123456, templateName: Agreement checklist} running ApprovalNode {id: 371441119, name: LOB SMB Approval}
WorkflowLogger|INFO|2023-03-29 13:49:40,790|datacard {id: 123456789, name: Ticket name| EFE-123456, templateName: Agreement checklist} running ApprovalNode {id: 371441119, name: LOB SMB Approval}
6. WorkflowLogger|INFO|2023-03-29 13:49:41,748|datacard {id: 123456789, name: Ticket name| EFE-123456, templateName: Agreement checklist} running ApprovalNode {id: 371441165, name: Credit Committee Approval }'
WorkflowLogger|INFO|2023-03-31 06:47:55,392|datacard {id: 123456789, name: Ticket name| EFE-123456, templateName: Agreement checklist} running ApprovalNode {id: 371441165, name: Credit Committee Approval}
7. WorkflowLogger|INFO|2023-03-31 06:47:56,496|datacard {id: 123456789, name: Ticket name| EFE-123456, templateName: Agreement checklist} running EmailNode {id: 371441190, name: Notify onboarding team }
8. WorkflowLogger|INFO|2023-03-31 06:47:56,748|datacard {id: 123456789, name: Ticket name| EFE-123456, templateName: Agreement checklist} running ConditionNode {id: 371440832, name: Check risk amount }
9. WorkflowLogger|INFO|2023-03-31 06:47:56,748|datacard {id: 123456789, name: Ticket name| EFE-123456, templateName: Agreement checklist} run then path:Then
10. WorkflowLogger|INFO|2023-03-31 06:47:56,892|datacard {id: 123456789, name: Ticket name| EFE-123456, templateName: Agreement checklist} running WaitConditionNode {id: 371440854, name: Waiting for initial approval }
WorkflowLogger|INFO|2023-03-31 06:47:56,892|datacard {id: 123456789, name: Ticket name| EFE-123456, templateName: Agreement checklist} Conditions were not met. NodeId: WaitConditionNode{id='371440854', name='Waiting for initial approval', criteria=ConditionCollection[booleanOperator=AND,conditions=[SimpleCondition[operator=EQUAL_TO,leftOperand=AttributeOperand[groupAttributeId=119738157,ids=[371440842]],rightOperand=StaticValueOperand[value=StaticValueDTO[value=Initial approval,code=initial_approval,staticValueId=133859530],isOpen=false,id=371440844],id=371440847]],id=371440851]}. Workflow is pending for conditions of this node to be met before continuing.
11. WorkflowLogger|INFO|2023-03-31 08:53:03,606|datacard {id: 123456789, name: Ticket name| EFE-123456, templateName: Agreement checklist} running WaitConditionNode {id: 371440854, name: Waiting for initial approval }
WorkflowLogger|INFO|2023-03-31 08:53:03,606|datacard {id: 123456789, name: Ticket name| EFE-123456, templateName: Agreement checklist} Conditions were met. NodeId: WaitConditionNode{id='371440854', name='Waiting for initial approval', criteria=ConditionCollection[booleanOperator=AND,conditions=[SimpleCondition[operator=EQUAL_TO,leftOperand=AttributeOperand[groupAttributeId=119738157,ids=[371440842]],rightOperand=StaticValueOperand[value=StaticValueDTO[value=Initial approval,code=initial_approval,staticValueId=133859530],isOpen=false,id=371440844],id=371440847]],id=371440851]}. Workflow proceeds.
12. WorkflowLogger|INFO|2023-03-31 08:53:03,883|datacard {id: 123456789, name: Ticket name| EFE-123456, templateName: Agreement checklist} running SetValueNode {id: 371441300, name: Set decision to approved }
13. WorkflowLogger|INFO|2023-03-31 08:53:04,060|datacard {id: 123456789, name: Ticket name| EFE-123456, templateName: Agreement checklist} running EndpointNode {id: 371440960, name: Closed }

Exempel på ett arbetsflöde med numrerade referenser till arbetsflödesloggsnuttet:

Loggning av arbetsflödeskörning och misslyckade datakortssparningar

När en lyssnare eller hanterare hindrar arbetsflödet från att spara ett datakort dokumenteras händelsen i itsm.log-filen istället för i arbetsflödesloggen. Fel av detta slag registreras i loggposter som vanligtvis visas enligt följande:

ErrorLogger|ERROR|2023-05-25 13:43:14,116|QuartzScheduler_Worker-3||Job (workflow.7548098#7546966#7546920#0 threw an exception.
org.quartz.SchedulerException: Job threw an unhandled exception. [See nested exception: com.bitmount.boas.exception.PersistenceException: com.efecte.datamodel.entity.action.FatalDataCardActionException: Data card save failed due to fail_card attribute having a value.]
at org.quartz.core.JobRunShell.run(JobRunShell.java:213)
at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:573)
Caused by: com.bitmount.boas.exception.PersistenceException: com.efecte.datamodel.entity.action.FatalDataCardActionException: Data card save failed due to fail_card attribute having a value.

Det sista ID:t på den första raden anger den specifika arbetsflödesnoden där processen stoppas.

I arbetsflödesloggen visas det som om kortet stannar vid noden där det misslyckade sparandet inträffade. I användargränssnittet indikerar dock arbetsflödessteget (som visas längst upp till höger i kortvyn) att det befinner sig vid en tidigare nod. Denna skillnad uppstår eftersom kortet faktiskt återgår till den första föregående noden "timer" eller "väntevillkor" innan sparningen misslyckades.