Im Standard enthaltene Checks deaktivieren

Hallo allerseits,

im Moment läuft bei uns Dynamics Nav 2016, sind aber schon in den Anfängen eines Updates auf BC.
Im Nav kann ich ja ganz unbesorgt an den Standardobjekten rumhantieren, das ist ja bei BC dann eher schwierig (on premise) oder ganz unmöglich (SaaS), soweit ich das richtig verstanden habe. Daher der Wunsch Änderungen, die ich noch am Nav mache so zu machen, dass sie nachher einfach auf BC zu portieren sind.

Jetzt hab ich in T5940 Service Item einen Check den ich gerne ignorieren würde (und an einer anderen Stelle auch, aber bleiben wir bei einem Beispiel). Normalerweise würde ich die Zeile einfach auskommentieren:

Code:

Customer No. - OnValidate()
IF "Customer No." <> xRec."Customer No." THEN BEGIN
  IF CheckifActiveServContLineExist THEN
    ERROR(
      Text004,
      FIELDCAPTION("Customer No."),"Customer No.",TABLECAPTION,"No.");
      ServItemLinesExistErr(FIELDCAPTION("Customer No.")); // Diese Zeile wär auszukommentieren.
  IF ServLedgEntryExist THEN
    IF NOT CONFIRM(
...


Allerdings hab ich keine Ahnung wie man das BC-konform umsetzen könnte. Ich vermute mal, dass einfach an einen Trigger hängen läuft nicht, weil egal, was ich vorher oder nachher mache, der Check läuft dazwischen trotzdem.
Und krasse Verenkungen indem ich die entsprechenden ServiceItemLines zwischenspeichere, die Originale lösche und nach dem Check wieder zurückspiele, will ich nicht unbedingt machen (abgesehen davon, dass dann beim Wiedereinspielen vielleicht Validierungsprobleme auftauchen).

Irgendwelche Ideen, wie ich sowas BC-konform umsetzen kann?

Falls im neuen System

Code:

IF IsHandled THEN
EXIT;

vorhanden ist, kann man das nutzen um Codeausführungen im Standard durch eigene zu ersetzen. Beispiel hier:
IsHandled flag and exit a return value
Falls dagegen Änderungen an Events usw. notwendig sind, muss man MS kontaktieren wie hier beschrieben.

Leider ist IsHandled nicht skalierbar, wenn also mehrere Subscriber sich an diesen Publisher hängen, hängt es von der Ausführungsreihenfolge ab, welche App den Quellcodedurchlauf als IsHandled betrachtet. Wenn z.B. eine andere App auf diese Prüfung angewiesen ist und die eigene zuerst ausgeführt wird (das hängt von der App-ID ab) dann wird die u.U. nicht mehr korrekt arbeiten.

Hallo,

Leider ist IsHandled nicht skalierbar, wenn also mehrere Subscriber sich an diesen Publisher hängen, hängt es von der Ausführungsreihenfolge ab, welche App den Quellcodedurchlauf als IsHandled betrachtet. Wenn z.B. eine andere App auf diese Prüfung angewiesen ist und die eigene zuerst ausgeführt wird (das hängt von der App-ID ab) dann wird die u.U. nicht mehr korrekt arbeiten.

IsHandled ist schon skalierbar. Es werden zunächst alle Eventsubscriber aufgerufen.
Ob die dann schon auf IsHandled reagieren, also die eigene Verarbeitung abbrechen, ist deren Sache. Ob die dann auch ein gesetztes IsHandled gesetzt lassen, ist auch deren Sache. D.h. wenn dein Subscriber IsHandled setzt, ist nicht sicher das dieser Status auch bei der dem Event nachfolgenden Abfrage "IF IsHandled..." als solche ankommt, weil jeder deinem eigenen nachfolgende Subscriber den IsHanded auch wieder auf FALSE setzen kann (was sicherlich aus Unachtsamkeit passieren wird) .

Gruß Fiddi

IsHandled ist schon skalierbar.

Präziser: Nur schlecht skalierbar, weil ein Boolean nur TRUE oder FALSE sein kann. Wenn der letzte Subscriber IsHandled auf FALSE setzt, dann kommt anschließend die Codeausführung im Standard doch noch zum Zuge, die man ja eigentlich verhindern wollte.

Beim Verwalten von aktualiserten und veralteten Extensions gibt es zumindest Konzepte für eine bessere Lösung, siehe Post bei Yammer von Jesper-Schulz-Wedde von heute hier: https://www.yammer.com/dynamicsnavdev/t ... 9118866432
Leider ist für IsHandled nichts dergleichen angekündigt.