search

admstar / rivta

Automatically exported from code.google.com/p/rivta
0 stars 0 forks source link

bookingId saknas i response för updatebooking #67

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
I svaret på interaktionen UpdateBooking returneras inget bookingid vilket är 
lite ologiskt eftersom man får detta från MakeBooking. Eftersom bookingid kan 
bytas vid ombokning (beroende på hur aktuell producent vald att göra) så 
skulle vi behöva införa detta även i update för att vara konsekventa och 
konsumenten MVK lagrar idag bookingId i bekräftelse

Original issue reported on code.google.com by bjorn_he...@hedmanhome.se on 11 Apr 2013 at 7:59

GoogleCodeExporter commented 9 years ago 
Men bookingId är ju obligatoriskt i svaret enl. TK-beskrivningen? Dock tycker 
jag det behöver förtydligas att det kan vara ett annat booking-id, om det är 
så att det ska vara möjligt. Jag tycker det är olyckligt om det måste kunna 
bytas, eftersom det innebär borttag och uppdatering i EI, vilket signalerar en 
annan händelse än att det skett en uppdatering. På vilka grunder behövs 
(det nya) kravet att byta booking-id på en befintlig bokning inom en 
mottagning?

Original comment by johan.el...@callistaenterprise.se on 11 Apr 2013 at 8:10

GoogleCodeExporter commented 9 years ago 
Såvitt jag kan se så returneras inget bookingid i svaret på updatebooking 
det enda som returneras är resultcode och resulttext..

<xs:complexType name="UpdateBookingResponseType">
    <xs:sequence>
      <xs:element name="resultCode" type="core:ResultCodeEnum" minOccurs="1" maxOccurs="1" />
      <xs:element name="resultText" type="xs:string" minOccurs="0" maxOccurs="1" />
      <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
  </xs:complexType>

Original comment by bj...@eqit.se on 22 Apr 2013 at 2:04

GoogleCodeExporter commented 9 years ago 
Har kikat lite ytterligare på detta. Anledningen till att det returneras från 
MakeBooking är att MakeBooking skapar id:t. ID:t ska sedan gälla ända fram 
till tiden är passerad eller att den ställs in. Någon som sparat ett 
bokningsid måste kunna lita på att det gäller för den bokningen. Det 
kopplar även till uppdatering av engagemangsindex.

Original comment by johan.el...@callistaenterprise.se on 23 Apr 2013 at 8:27

GoogleCodeExporter commented 9 years ago 
Det är ju dock lite svårt att entydigt utläsa detta ur 
tjänstekontraktsbeskrivningen även om det vore en sund princip. Här måste 
vi nog både kolla av med dagens befintliga producenter hur användningen är 
samt planera in en tydligare beskrivning av dessa regler. och dessa kan då 
eventuellt inte införas utan Major uppgradering ifall dagens befintliga 
producenter använder bookingid som en referens till en viss tidslot

Original comment by bj...@eqit.se on 29 Apr 2013 at 8:39

GoogleCodeExporter commented 9 years ago 
Du har rätt. Mitt resonemang håller inte. Bokningsid måste få ändra sig. 
Men hela domänens "konstruktion" bygger väl då på att 
GetSubjectOfCareSchedule alltid föregår UpdateBooking. Något annat flöde 
stödjs helt enkelt inte. Det kanske är på den nivån ett nytt krav bäst 
diskuteras? Att beskriva vilket nytt flödesbehov som uppstått och vilka 
förändringsbehov det driver på enskilda tjänstekontrakt?

Original comment by johan.el...@callistaenterprise.se on 29 Apr 2013 at 9:23

GoogleCodeExporter commented 9 years ago 
Det finns ett annat flöde, en uppdatering via Engagemangsindex ska ge det nya 
BookingId och utifrån den kan sen en update booking göras.

Original comment by anders.f...@callistaenterprise.se on 29 Apr 2013 at 9:35

GoogleCodeExporter commented 9 years ago 
Ok. Men det kanske fungerar med nuvarande kontrakt?

Original comment by johan.el...@callistaenterprise.se on 29 Apr 2013 at 9:45