...
Engagemangsindex applikationsloggar återfinns default under lagras i foldern <MULE-HOME>/logs
/mule-app-ei.log.. EI's frontend- och backend-applikation har vars en log-fil:
mule-app-skltp-ei-application-mule-frontend-app-1.0.0.log
mule-app-skltp-ei-application-mule-backend-app-1.0.0.log
För mer information om EI's uppdelning i frontend- och backend-applikation se avsnittet deployment-vy i EI's SAD.
Förväntade sekvenser av log-händelser
I denna sektion beskrivs förväntade sekvenser av log-händelser för de användningsfall som beskrivs i EI's SAD.
I en felsökningssituation kan dessa sekvenser användas för att skapa sig en förståelse för hur långt berabetningen kommer i en specifik felsituation genom att jämföra log-händelser från felsituationen med de förväntade sekvenserna som anges i denna sektion.
För att beskriva de förväntade sekvenserna används skltp's "realtids log viewer".
Användningsfallen "uppdatering", "bearbetning" och "notifiering"
Här beskrivs förväntade sekvenser av log-händelser för användningsfallen:
1. Källsystem uppdaterar engagemangsindex
2. Engagemangsindex bearbetar inkomna uppdateringar och notifieringar
5. Prenumerant tar emot förändringar från ett engagemangsindex
Exemplet nedan är baserat på:
- Ett källsystem med HSA-ID "
client
" skickar in en uppdatering via EI's update tjänst. - EI's update-tjänst lägger uppdateringen på JMS-kön med namnet "
skltp.ei.process
" och returnerar ett svar till källsystem - EI's process-tjänst uppdaterar databasen och lägger en notifiering om uppdateringen på JMS-topicen med namnet "
skltp.ei.notify
" - EI's notifierings-tjänst notifierar en prenumerant med HSA-ID "
demo-ei-notify-publisher
"
Användningsfallet "sök innehåll"
Här beskrivs förväntade sekvenser av log-händelser för användningsfallen:
6. Tjänstekonsument begär information från ett engagemangsindex
TBS
Användningsfall som saknar förväntade sekvenser av log-händelser
2. Engagemangsindex hämtar uppdateringar från ett källsystem
3. Federerat engagemangsindex uppdaterar engagemangsindex