Behov av konsument-anpassad notifiering

Issue #197 open
Former user created an issue

Idag är det allt eller inget om man är producent av ProcessNotification. Ex: om man bygger en anpassningstjänsten för vaccinationsrapportering till SMI genom att prenumerera på EI-händelser, kommer anpassningstjänstens ProcessNotification-producent att bli anropad varje gång det sker en uppdatering av EI, oavsett vilken tjänstedomän uppdateringen avser. Det innebär att anpassningstjänsten för vaccinationsrapportering till Smittskyddsinstitutet kommer att få flera 100 gånger fler anrop än vad som egentligen behövs. För att undvika detta önskas att EI-domänen uppdateras till att kravställa producent-anpassad notifiering via någon form av konfiguration. Åtminstone med krav att kunna filtrera på EI-händelsens tjänstedomän.

#####Originally written by johan [eltesconsulting.se] on code.google.com

Comments (11)

  1. Former user Account Deleted

    Filtrering på åtminstone tjänstedomän och gärna också på ytterligare attribut i EI vore vägen framåt fär att notifieringsbaserade lösningar skall bli effektiva.

    #####Originally written by marcus.claus [glocalnet.net] on code.google.com

  2. Former user Account Deleted

    Notifieringsfilter

    En notifieringsmottagare bör kunna: - Välja från vilken verksamhet(hsa-id) som notifieras. - Välja från vilket system(hsa-id) som notifieras. - Välja från vilken tjänstedomän som notifieras. o Här inkluderar vi väl version. - Vilken ”categorization” som skall notifieras.

    Övrigt - Categorization bör kunna uppdateras i en IE post. - Expire flagga på en IE post. Någon form av rensningsjobb.

    #####Originally written by marco.deluca [delucaconsulting.se] on code.google.com

  3. Former user Account Deleted

    Johan: Tack för inputen. Inte säker på att riv-ta issues är bästa stället att begära interna förändringar av en komponent. EI's tjänstekontrakt i sig kommer ju inte påverkas av detta tänker jag. Men vi kör på så här för denna gången så klart :-)

    Marcus: Tjänstedomän och kategori är det som ligger i planen nu.

    Marco #1: Kan du förklara behovet du ser av att filtrera även på verksamhets och system hsa-id? Jag ser en fara med allt för fingranulär filtrering i EI då det rimligen kommer medföra en rejäl ökad börda på TP-supporten. Om vi hade självbetjäning i TAK så skulle det vara en annan sak men så länge det måste gå genom TP'supporten så ställer jag mig tveksam. Kan du förklara dina behov lite mer så kan vi ta det som utgångspunkt för fortsatt diskussion?

    Marco #2: Får jag be dig registrera nya ärenden för det du lagt in under "övrigt". Det finns inga praktiska möjligheter att ha en effektiv ärendehantering om vi tillåter oss blanda ihop olika önskemål i ett och samma ärende.

    Tips #1: Johanna har ju efterfråga intresse av att delta i ett möte i närtid för att kunna diskutera EI-filter lösningen, tror ni alla tre fått mail om det. Anmäl gärna intresse till det mötet. Tror det kan vara snabbaste sättet att landa diskussionen om behov och vad vi skall prioritera i den första versionen av EI-filer som vi bygger nu.

    Tips #2: På issue 200 kan ni hitta info om planeringen av arbetet med EI-filer.

    #####Originally written by magnus.larsson [callistaenterprise.se] on code.google.com - Status changed: Assigned.

  4. Former user Account Deleted

    Mycket bra att tjänstedomän och kategori är spikad!

    #1 Jag tycker inte att TP förvaltningens brist på IT stöd skall styra nationell IT utveckling. Som jag ser det kan det finnas behov av att peka på specifika system (t.ex. system adresserade domäner som formulärtjänst). Det skulle kunna vara så att olika formulärmotorer betjänar olika special områden. Alternativet är att notifieringar istället kastas av mottagaren.

    När det gäller verksamheter så kan det komma tillämpningar som samverkar i process vilket då skulle kunna optimeras om filtrering kan ske centralt. Idag saknas verksamhetens hsa-id EI posten.

    #####Originally written by marco.deluca [delucaconsulting.se] on code.google.com

  5. Former user Account Deleted

    Marco: Tack för återkopplingen.

    #####Originally written by magnus.larsson [callistaenterprise.se] on code.google.com

  6. Former user Account Deleted

    Magnus: Jag ser dessa krav som generella för en konsument av ProcessNotification. Idag specas kravet i tjänstedomänen avseende ProcessNotification och beteende för såväl konsument och producent. Det är i ljuset av det som jag startade tråden här. Jag tycker definitivt att det är en domänfråga för intressenterna och att det därmed hör hemma i i TKB:n (även fortsättningsvis). Jag håller förstås med om att det inte påverkar lire-protokollet, men tjänstekontrakten spexar ju mycket mer än så (semantik i konsument/producent, SLA).

    #####Originally written by johan [eltesconsulting.se] on code.google.com

  7. Former user Account Deleted

    Johan: Låter vettigt, tack. Vi får beskriva i TKB:n att det finns en förväntan på en konsument av ProcessNotification att den kan filtrera anrop.

    #####Originally written by magnus.larsson [callistaenterprise.se] on code.google.com

  8. Former user Account Deleted

    TKB behöver speca krav på en EI-realisering avseende prenumerationsmasker per logisk adressat av ProcessNotification. Förslagsvis ska masken kunna användas för att filtrera utgående från samtliga fält i en ProcessNotification-begäran och uttryckas i någon form av standardiserat, enkelt regel/el-språk. Regelspråket bör pekas ut i TKB för att underlätta migrering och återanvädning av prenumerationsmasker mellan EI-produkter/lösningar.

    #####Originally written by johan [eltesconsulting.se] on code.google.com - Labels added: Priority-High

  9. Log in to comment