Baramundi-Sync :: InciState wird beim Anlegen einer neuer Version zurückgesetzt.

[Frank Niethardt]

Hallo,

uns ist letztens aufgefallen, dass beim Syncen von Geräten aus Baramundi der Vorfallstatus immer wieder auf grün gesetzt wird. Ich hab dann die entsprechende Stelle im XSLT gefunden und einfach auskommentiert, so dass dieser Wert nicht mehr im JSON auftaucht, der zur Versions-Aktualisierung rangezogen wird. Bei der Action ist angegeben, dass er Werte aus der Vorversion übernehmen soll.

Trotzdem ist der Vorfallstatus nach dem Import wieder Operational. Ist das so gewollt?

Viele Grüße
Frank

[ITSM_enjoyer]

Hallo Frank,

Vorfallstatus und Verwendungsstatus sind Pflichtattribute beim Anlegen von neuen Assetversionen, daher muss irgendein Wert spezifiziert werden. D.h. wenn es im Mapping kein Attribut dafür findet, wird operational gesetzt. Aber wenn ein Attribut existiert, sollte er das schon berücksichtigen. Eventuell ist das dann ein Bug, wenn das Mapping so ok ist.

[Frank Niethardt]

Ich schrieb ja, es geht um Aktualisierungen und "Bei der Action ist angegeben, dass er Werte aus der Vorversion übernehmen soll.".

Wäre es nicht schön, wenn hier ein KIX Mitarbeiter wäre, der rausfinden kann, ob das ein Bug ist? ;)

Viele Grüße
Frank

[ITSM_enjoyer]

Ich hab dich schon verstanden, deswegen ja mein Hinweis: wenn das Mapping ok ist, könnte das ein Bug sein.

Um das sauber bewerten zu können, bräuchte man ja aber ein konkretes Beispiel (XSLT Mapping + Payload), mit dem man das Verhalten reproduzieren kann. Sonst ist jede Aussage auch nur Spekulation, das hilft dir ja auch nicht weiter.

[Frank Niethardt]

Im JSON, welches als "neue Version" reingereicht wird, ist InciState nicht vorhanden. Aber der Haken für "Werte aus Vorgängerversion übernehmen". Meine Annahme war, dass er den InciState dann auch von der Vorgängerversion übernimmt.

Wenn dem nicht so ist, werde ich in dem Synchronisationslauf irgendwie rausfinden müssen, wie der InciState aktuell ist und ihn wieder in das JSON reinreichen...

[ITSM_enjoyer]

Ich gebe dir Recht, dass das die logische Annahme für die meisten wäre. Umgesetzt ist es derzeit so, dass wenn solche Pflichtfelder im Mapping komplett fehlen, KIX den Standardwert setzt.

Damit auch hier in dem Fall die Vorgängerwerte übernommen werden, müsste IncidentState mit auftauchen, wenn auch leer ohne Wert. Dann sollte es klappen, dass er den Wert aus der Vorversion übernimmt wenn der Haken gesetzt ist. Aber komplett ohne Mapping geht er auf Default.

[Torsten Thau]

Hallo,

ja ich denke das ist ein Fehler - ich habe das mal erfasst. Es muss nur das XSLT-Mapping angepasst werden dann sollte es passen. Wenn es eine Lösung gibt wird es bei spezifischen Anpassungen den Bedarf einer manuellen Korrektur geben. 

vG, Torsten

[Frank Niethardt]

Moin,

also leer übernimmt er es nicht. Ich hab jetzt den aktuellen mit GetObjectData heraus gepopelt und liefer ihn bei der neuen Version mit. So bleibt er erstmal, wie er ist.

Viele Grüße
Frank

[Torsten Thau]

Hallo,

ich habe eben getestet ob eine Nicht-Angabe des Deployment- und Incident-Status das Update eines bestehenden Assets verhindert. In V35 habe ich dazu einen Job konfiguriert der auf der Admin-Schulung 103 basiert und auf die Angabe der Status und der KlassenID vollständig verzichtet. Der Job hat funktioniert und eine neue Version des bestehenden Assets erzeugt.




Damit sollte folgende Anpassung im XSLT-Mapping der Aufbereitung der OPSI- bzw. Baramundi-Daten ausreichend sein:

Stelle im XSLT-Mapping wie sie jetzt ist (ausgeliefert wird):

Code Auswählen Erweitern

          <DeplStateID>
            <xsl:value-of select="$DeplStateID"/>
          </DeplStateID>
          <InciStateID>
            <xsl:value-of select="$IncStateID"/>
          </InciStateID>


Stelle im XSLT-Mapping wie sie sein soll (voraussichtlich ausgeliefert werden wird):

Code Auswählen Erweitern

        <!-- only set Deployment-/Incident State for new assets -->
        <xsl:if test="string-length($AssetID) < 1 ">
          <DeplStateID>
            <xsl:value-of select="$DeplStateID"/>
          </DeplStateID>
          <InciStateID>
            <xsl:value-of select="$IncStateID"/>
          </InciStateID>
        </xsl:if>

Das ist, zugegebenermaßen, nicht getestet sondern bislang nur Zwischenergebnis einer schnellen Issue-Analyse - ggf hilft es aber bereits jemanden.

VG, Torsten

@Frank: ich weiß nicht warum bei Dir das ohne Angabe der beiden Parameter nicht geklappt hat, ggf. war auch eine Neuanlage dabei - diese scheitert dann natürlich, da in diesem Fall keine vorherigen Werte bezogen werden können.

[Frank Niethardt]

@Torsten evtl. weil ich immer Deployment Status mit setze (ungetestet)? Immerhin kann ein bestehendes Asset ja auch deaktiviert werden?

Achso, mein Problem war auch nicht, dass es keine neue Version gab, sondern dass die neue Version immer wieder den Incident Status zurück auf grün gesetzt hat...

[Torsten Thau]

Ja, der hier im Thread gemeldete Fehler bezieht sich nicht nur auf Incident-Status. 

Wir hatten die Arbeitsthese, dass nur produktive Geräte in Barmundi/Opsi enthalten sind. Das ist aber nicht immer passend. Schon der Status "In Reparatur" würde dem entgegen stehen. Daher habe ich nun das Setzen der Status (Plural) nur bei Neuanlage eines Assets angenommen. 


VG, Torsten