Datakortlyssnare i Matrix42 Professional

Datakortlyssnare är en mekanism för att implementera affärslogik i Matrix42 Professional (ESM). De är utformade för att reagera på specifika händelser i M42 Pro -mallar, vilket möjliggör automatiserade åtgärder baserade på definierade villkor. När en mall har en lyssnare kan alla datakort som skapas utlösa lyssnaren när de sparas:

Exekveringsordning: se artikeln ” Spara Pro i M42 Pro ”.

Konfigurera datakortlyssnare

Datakortlyssnare konfigureras med hjälp av XML-filer som definierar lyssnarens egenskaper och beteenden. Konfigurationsprocessen innefattar:

1. Skapa XML-konfiguration : Lyssnarens beteende och villkor definieras i en XML-fil. Denna fil anger hur lyssnaren ska interagera med datakortshändelserna.
2. Importera till M42 Pro -mallen : När XML-konfigurationen har skapats måste den importeras till relevant M42 Pro -mall. Detta steg aktiverar lyssnaren i mallen.
3. Justera ordningen på lyssnare : Försparningar körs först i sin sekventiella ordning, sedan eftersparningar på samma sätt. Det är relevant vilken som körs först. Till exempel, placera valideringslyssnare först vid försparning. Flytta lyssnarna för att återspegla rätt körordning.

Lyssnare kan också exporteras som en del av den övergripande M42 Pro -konfigurations-XML:en, vilket möjliggör enkel replikering och distribution i olika miljöer.

Lyssnarfunktionalitet och triggerinställningar

Varje M42 Pro -mall kan innehålla en eller flera lyssnare. När datakortet som är kopplat till en mall sparas, meddelas alla lyssnare som är registrerade för den mallen om händelsen.

Lyssnare konfigureras för att reagera på specifika händelser baserat på deras triggerinställningar, vilka kan vara antingen:

• Försparningsutlösare : Lyssnaren aktiveras innan datakortet sparas. Den ändrar endast källdatakortet .
• Utlösare efter sparning : Lyssnaren aktiveras efter att datakortet har sparats. Den modifierar endast andra datakort.
  • Om det inte finns ett specifikt behov av att modifiera ett källdatakort och avsiktligt utlösa en andra sparcykel på det. En exempelsituation är att byta statusvärde på ett ärende med en lyssnare, men vill utlösa DataCardHiddenState- och ValueChange-hanterare för att återspegla ändringen när det görs.

När lyssnaren utlöses utvärderar den om den ska reagera på händelsen. Detta beslut baseras på definierade källvillkor, vilka är kriterier som anges i lyssnarens konfiguration. Källvillkoren avgör om källdatakortet (dvs. det sparade datakortet) matchar de parametrar som krävs för att lyssnaren ska agera. På liknande sätt, för att rikta ändringar till specifika måldatakort i en annan mall, bestämmer målvillkoren i början av åtgärdskedjeavsnittet målet/målen.

• Flera lyssnare : En enda mall kan stödja flera lyssnare, som var och en svarar på olika utlösare eller villkor.
• Villkorlig logik : Lyssnare reagerar bara på händelser om de angivna villkoren är uppfyllda, vilket möjliggör exakt kontroll över när och hur affärslogik tillämpas.

Bästa praxis

Var försiktig med: Skapa konstruktioner där du uppdaterar samma datakort flera gånger med olika lyssnare efter sparning. Konflikter mellan lyssnare och andra hanterarbaserade funktioner.

Allmän

Lyssnarens XML kan kommenteras med ett <!-- foobar -->-avsnitt, men kommentarerna tas bort när lyssnaren importeras till M42 Pro (dvs. kommentering av lyssnare är endast användbart om lyssnarens "masterdata" lagras någon annanstans).

• Du kan lägga till mer än en handlingskedja
  • Om du till exempel skulle behöva röra flera olika målmallars datakort i en lyssnare för att spara inlägg, baserat på samma källvillkor.
• Undvik att använda djupa/flernivå kombinerade AND-ELLER-AND..-villkor för att göra lyssnarkoden mer begriplig och försök istället antingen förenkla villkoren eller använda den mer komplexa logiken i uttryckskoden i ett hjälpattribut.
  • Tips: attributet uttryckshjälp kan ställas in som en flervärdessträng för att möjliggöra att flera värden ställs in i ett hjälpattribut som lyssnarna kan använda som olika utlösare.

XML

• Traditionell metod för att skapa affärslogik/köra icke-fältbaserade automatiska funktioner på en viss mall.
  Konfigureras genom att skapa en lämplig XML-konfiguration.
  • Lyssnare tas i bruk genom att importera denna XML till en M42 Pro -mall.
  • Lyssnare kan exporteras som en del av M42 Pro -konfigurationens XML.
• Att ordna i ordning är något att tänka på.
  • Först försparas i ordning, sedan eftersparas i ordning per mall.
• Försparade lyssnare:
  • Körde och kontrollerade varje datakortssparning, efter alla hanterare utom AutoMailSender och TargetDeleter.
  • Används på datakort för "denna" mall.
• Lyssnare efter sparning:
  • Används vanligtvis på datakort för andra mallar relaterade till datakortet för "denna" mall.
  • Kan inkludera målvillkor.
  • Kan utlösa en sekvens på nytt på en annan mall.
  • Hanterare på målmallen körs efter dessa

Att skicka strängdata till ett referensfält med ändrings- eller kopieringsåtgärden kanske inte fungerar.

• Traditionellt skulle du behöva pusha entityid om du vill länka till ett visst datakort.
• Att kopiera referens till referens borde fungera.
• Enklare att länka referenser med uttryck i de flesta fall, men när man till exempel gör transformationer kan man behöva använda lyssnare för att göra vissa referenser efteråt.

Akta:

• Skapa konstruktioner där du uppdaterar samma datakort flera gånger med olika lyssnare för sparade filer.
• Konflikter mellan lyssnare och andra hanterarbaserade funktioner.
• Bestämmer körordningen.

KOM IHÅG : Du måste uppdatera statistiska datetime-taggar med lyssnaren om du stänger datakort med datechecker – lyssnarautomation. Den här metoden är ett nybörjarsätt för att göra det ofullständigt och på ett hårdkodat sätt, vilket inte är flexibelt i längden. Observera att detta inte är möjligt i en situation där du skulle behöva skapa ValueChanges. Ett mer flexibelt, men komplicerat sätt, är att använda post save och sedan utlösa lämpliga hanterare (som sedan kan variera beroende på deras konfiguration efter att lyssnarna har skapats).

Importera en lyssnare

När en lyssnare importeras validerar M42 Pro innehållet och strukturen i XML:

• Felmeddelandet som visas är ofta otolkbart, till exempel ”XML kan inte vara tomt”.
• Kontrollera att du har stängt alla XML-taggar </> och att alla attributkoder är korrekta etc.
• Granska lyssnardokumentationen och se till att du inte försöker göra saker som inte är möjliga, som att jämföra textfält eller externa referensfält.
• Försök att ta bort eller modifiera misstänkta komponenter och försök utan dem.

Använda loggning och felsökning

• Du kan försöka extrahera ytterligare information genom att öppna några av dessa klasser för runtime-loggning och ställa in DEBUG-nivån när du försöker importera XML-filen.
  • com.bitmount.equipment.action.TemplateListenerImport  kontrollera detta i de flesta fall
  • com.bitmount.equipment.importing.ValidatingEntityXMLImporter
  • com.efecte.datamodel.entity.listener.importing.XMLActionChainImporter
  • com.efecte.datamodel.entity.listener.importing.XMLDataCardListenerImporter
  • com.efecte.datamodel.entity.listener.importing.XMLSourceConditionsImporter
  • com.efecte.datamodel.entity.listener.importing.XMLTemplatesDataCardListenerImporter
• Kom ihåg att ställa tillbaka loggningen till INFO-nivå efter att du har åtgärdat lyssnarna, annars kommer du att producera enorma mängder loggfiler!!
• Lyssnaren importerades men fungerar inte som den skulle
• Kontrollera runtime-loggarna och ställ in DEBUG-nivån så bör du se vad som utlöses och vad som inte gör det.
  • Källförhållanden
    • com.efecte.datamodel.entity.listener.condition.(?????)
  • Målförhållanden
    • com.efecte.datamodel.entity.action.chain.condition.(?????)
  • Åtgärder
  • com.efecte.datamodel.entity.action.implementations.(?????)
  • (?????) = varje XML-komponent
• Kom ihåg att ställa tillbaka loggningen till INFO-nivå efter att du har åtgärdat lyssnarna, annars kommer du att producera enorma mängder loggfiler!!
• Plattformsinställningar för lyssnare
  • datacard.listeners.run.as.root

Ändring av ärendestatus

Om du ändrar ett ärendestatusvärde med lyssnaren bör du överväga följande:

• Statistikens tidsstämplar uppdateras därefter
• Värdeändringshistoriken för status uppdateras därefter
• Möjligen dölj/sätt synlig datakortet uppdateras därefter
• Om du anger ett fält med en lyssnare för försparad funktion, förvänta dig inte att ett uttryck körs baserat på det om du inte gör det inuti lyssnaren!
• Om du tar bort ett attribut relaterat till en lyssnare, blir lyssnaren trasig.
  • Lyssnaren måste tas bort för att konfigurationen ska exporteras
  • I de flesta fall kan detta åtgärdas genom att återskapa det borttagna attributet med samma attributkod.

GuiRedigera

GuiEdit –villkor fungerar inte i dessa scenarier:

• ValueButton-hanteraren klickades i visningsläge
• TicketReservation-hanteraren klickade i visningsläge
• EntityStateMail skickades i visningsläge
• WorklogHandler-kommentar tillagd i visningsläge

Lägg alltid till GuiEdit när du utför AlwaysFailDataCardAction för att säkerställa att integrationsredigeringar inte blockeras av den och ha dessa alltid som de första lyssnarna i ordningen.

• Via administratörsgränssnittet kan du bara se namnen och sekvensen för lyssnare och du måste exportera hela konfigurationen i XML för att undersöka lyssnarnas faktiska funktioner.

Lyssnarordning

Håll lyssnare i körbar ordning: Försparningar körs först, sedan eftersparningar.

Namngivning

Håll en konsekvent namngivningsmetod!

• Överväg att namnge dem snyggt och informativt, till exempel inkludera de flesta av dessa:
  • Förspara eller efterspara
  • Ordernummer
  • Kort beskrivning
    • vad den gör
    • vad/varför det utlöser
  • Om flera personer administrerar eller utvecklar
    • Datum då ändringen skedde
    • Kanske till och med initialer eller förkortning av vem som modifierade

Exempel:

• förspara.Kopiera utvecklingsteam om värdet är tomt och tjänsten är vald-09.10.2019-AA
• presave.SET Löst inom SLA_04052021_MK
• postsave.4. Ange referenser om inkommande e-post genereras-04.05.2017
  

Lyssnare – Nuvarande värde sant vs. Nuvarande värde falskt

current_value false = Gammalt / Föregående värde

current_value true = Nytt / Nuvarande värde

<source_condition>
  <value>
    <attribute>
      <code>status</code>
      <current_value>false</current_value>
    </attribute>
    <operator>=</operator>
    <compared_value>01 - New</compared_value>
  </value>
</source_condition>
<source_condition>
  <value>
    <attribute>
      <code>status</code>
      <current_value>true</current_value>
    </attribute>
    <operator>=</operator>
    <compared_value>02 - Solving</compared_value>
  </value>
</source_condition>