# Verhalten Server und Client

### Prämissen
* Request kann immer vollkommen "dirty" sein, über Kaskade von Prüfungen muss dies validiert werden.
* Immer gültiges XML
* Aufbau des Requests entspricht dem a priori Produktwissen. Wenn dagegen verstoßen wird (Baustein oder Attribut), gibt es
möglichst sprechende Fehlermeldungen. Es ist aber ein Fehler zur Entwicklungszeit, d.h. es darf aber es muss keinen Produktbaum im
Response geben, einfache Fehlermeldung genügt. Es ist kein inhaltlicher Konfigurationsfehler, der über einen "schönen"
Response an den Client zur Korrektur gegeben werden muss.
* Response darf teilweise "dirty" sein, damit gute Fehlerhinweise möglich sind und der User leicht korrigieren kann.
* Client zeigt den Response an und keine Mischung aus seinem Request und dem Response. Damit
  Client und Server wieder synchron sind.
* Das Verhalten könnte Context-gesteuert sein, z.B.: 
  * Im Context "Produktvergleich" werden immer nur Fehlermeldungen geworfen
  * Im Context "Antrag", "Vertragsänderung" oder "Einzelkonfiguration" werden Empfehlungen abgegeben.
* Das Verhalten des Servers könnte sogar Produktabhängig definiert sein: An manchen Bausteinen Variante 1 an
anderen Variante 2 des Verhaltens.(?)
* Berechnung nur, wenn die Instanz (Antrag, Vertrag) erfolgreich plausibilisiert.
* Unterstützung für "Actions"?
* Verhaltenssteuerung: Im Request kann ein Profil vorgegeben werden. Im Response wird angegeben, ob es berücksichtigt werden konnte, oder Fallbackverhalten.
  * Basic - nur Fehlermeldungen, Baum wird nie verändert
  * Advanced - Fehlermeldungen und Änderungen im Baum (z.B. Anlage von Default-Elementen). Das Verhalten im Baum ist normiert.
  * Freestyle - Server reagiert innerhalb der vorgegebenen Möglichkeiten, wie er es an der Stelle für richtig hält. Sprich der
    Produktentwickler legt dies fest und kann das für Bausteine und Attribute festlegen.
  * Actions - es werden Actions angeboten, um Korrekturen im Baum vorzunehmen. 
  
## Fälle Bausteine

Der Client schickt einen Unbekannten Baustein. Der Server gibt eine Fehlermeldung zurück.
Der Client schickt einen Baustein mit einem fehlerhaften Attribut. Der Server gibt eine Fehlermeldung zurück.
Der Server schickt einen ungültigen Baustein. Der Server gibt eine Fehlermeldung zurück.


Der Client schickt zu viele von einem Baustein. A priori erstmal ausgeschlossen, da der  
Client über Produktwissen verfügt. Über Plausis in der Instanz kann der Fall trotzdem eintreten.
Der Server könnte:
1) Fehlermeldung in Oberbaustein senden
2) Die überzähligen Bausteine auf Inaktiv setzen und mit Fehler markieren
3) Den überzähligen Baustein / die überzähligen Bausteine entfernen

Der Client schickt zu wenig von einem Baustein. Der Server könnte:
1) Einen Default Baustein (mehrere Default-Bausteine) hinzufügen (er kann dabei die Daten des Requests in den 
Vorschlag einfließen lassen, was der Client nicht kann)
2) Eine Meldung über den Parent mitgeben, der Client ist dann zuständig den Baustein anzulegen.

Der Client schickt Bausteine, die sich wiedersprechen. Der Server könnte:
1) Fehlermeldung und beide belassen
2) Fehlermeldung und einen priorisieren und den anderen inaktiv setzen.
3) Fehlermeldung und beide inaktiv setzen

Der Client schickt einen Baustein in einem falschen Kontext. Der Server könnte:
1) Den Baustein dem richtigen Kontext zuordnen
2) Den Baustein inaktiv setzen


## Fälle Attribute

Attribut unbekannt - sollte gar nicht auftreten, muss nicht inhaltlich behandelt werden

Wert in Attribut ungültig - Attribut behält den falschen Wert, wird aber mit Fehlermeldung zurückgegeben.

Kardinalität Attribut überschritten: 
1) Fehler an Baustein
2) Fehler an überzähligen Attributen

Kardinalität Attribut unterschritten:
1) Fehler an Baustein aber keine automatische Ergänzung
2) Hinweis an Baustein, Ergänzen der fehlenden Attribute mit Defaultwerten.


