[Gelöst] RequestForm von Dataport nach Importende sichtbar..

Hallo zusammen,

ich habe das RequestForm eines Dataport modifiziert (gemäß einiger Anleitungen in diesem und anderen Foren), so dass ich das Verhalten des Dataport etwas beeinflussen kann.
Hintergrund ist: ich möchte den User durch Optionswahl entscheiden lassen, ob der Import zunächst nur als Prüflauf, oder als realer Datenimport absolviert wird.
Das Dataitem des Dataports ist 'Integer', so dass ich in den Triggern des Dataports beeinflusse, was genau wohin importiert wird.
Die konkrete Aufgabe des Dataports ist die spezifische Befüllung von Sales Hader und Sales Line mit Rechnungsdaten aus einem vorgelagerten CRM.
Der OnAfterImportRecord-Trigger des DataItem 'Integer' führt eine Reihe von Prüfungen auf Datenkonsistenz aus und befüllt mit den evtl. Konsistenzfehlern eine Tabelle, die ich in einem Subform, das ebenfalls auf dem Dataport-RequestForm angeordnet ist, darstelle.

Ich habe jetzt nur ein Problem: Sobald der Dataport seinen Durchlauf durch die Schnittstellendatei beendet hat, verabschiedet er sich, und mit ihm das RequestForm. So kann der User die Ergebnisse des Prüf- oder des Importlaufes natürlich nicht wahrnehmen.

Kann man an irgendeiner Stelle auf halbwegs elegante Art den Dataport bzw. dessen RequestForm am Schließen nach Durchlauf hindern?
Habe ich irgendeinen Zugriff auf die Buttons [OK], [Abbrechen], [Hilfe] des RequestForms?
Ich sehe diese Buttons nicht im Formular-Designer des RequestForm.

Ich bin absoluter Neuling in C/AL und C/SIDE Entwicklung. Komme eher aus der VB und .NET Ecke.

Leider schließt momentan auch aus, den Dataport aus einem 'normalen' Form anzusteuern, was evtl. als Workaround denkbar gewesen wäre. Wir können mit unserer Lizenz zwar Forms kreieren, kommen aber nicht an den C/AL Code.

Any Help?

Gruß, Thomas

Zuletzt geändert von Thomas Schulz am 4. Januar 2009 13:07, insgesamt 1-mal geändert.

Hallo Thomas,

herzlich willkommen in unserer Community und ein frohes neues Jahr.

Wie rufst du deine Form mit den Ergebnissen deiner Prüfung auf?
Ich vermute, dass du Form.RUN anstelle von Form.RUNMODAL verwendest, denn sonst würde die Verarbeitung angehalten, bis die Form geschlossen würde.

Wenn du auf [OK] der RequestForm des Dataports klickst, ist deine RequestForm zwangsläufig geschlossen, es sei denn, dass du im OnQueryCloseForm-Trigger der RequestForm abfragst, ob es sich um einen Prüflauf handelt.
Falls Ja, dann starte denselben Dataport aus dem Trigger und übergebe diesem per Funktion die notwendigen Daten.
Nichts desto trotz musst du die Form mit den Testergebnissen MODAL öffnen, denn wenn sich das Parent-Objekt schließt, werden automatisch auch alle Child-Objekte geschlossen.

Hintergrund ist: ich möchte den User durch Optionswahl entscheiden lassen, ob der Import zunächst nur als Prüflauf, oder als realer Datenimport absolviert wird.

Nur als Anregung:
Dies leistet der Standard schon von sich aus - wenn der Dataport aus dem [Korr]Object Designer Design-Modus[/Korr] heraus gestartet wird, dann werden keine Daten geschrieben (es wird aber alles durchlaufen und so auch auf Fehler gestoßen, als wenn der Dataport richtig gelaufen wäre).

Hintergrund ist: ich möchte den User durch Optionswahl entscheiden lassen, ob der Import zunächst nur als Prüflauf, oder als realer Datenimport absolviert wird.

Nur als Anregung:
Dies leistet der Standard schon von sich aus - wenn der Dataport aus dem Object Designer heraus gestartet wird, dann werden keine Daten geschrieben (es wird aber alles durchlaufen und so auch auf Fehler gestoßen, als wenn der Dataport richtig gelaufen wäre).

Hallo Natalie,

was verleitet dich zu der Annahme, dass ein Dataport nichts schreibt, wenn er aus dem Object Designer gestartet wird?
Einem Dataport ist es vollkommen egal, ob er aus dem Object Designer, per C/AL-Code oder durch ein Property (PushAction/RunObject) eines Buttons/MenuItems gestartet wird.
Einzig die Properties und/oder der C/AL-Code im Dataport entscheiden, ob tatsächlich Daten geschrieben werden.

Und unabhängig davon geht die RequestForm beim Klick auf [OK] (und natürlich auch [Abbrechen]) zu, von daher muss hier zwangsläufig im Trigger OnQueryCloseForm der RequestForm programmiert werden.

Auch Euch ein frohes und erfolgreiches Neues Jahr!
Danke für die WE-Arbeit, hat auch etwas gebracht.

Der Hinweis von Timo auf den passenden Trigger brachte den Erfolg. Ich hatte vorher mit anderen Triggern herumgespielt, die auf direkt das Schließen/Deaktivieren des Forms liefen - das war aber offenbar der falsche Weg.
Ich lasse jetzt gemäß dem Hinweis auf RUNMODAL die Fehlertabelle nicht mehr im Subform des RequestForm anzeigen, sondern starte explizit im OnQueryCloseForm des Dataports das Form für die Fehlertabelle modal.

Code:

//Dataport - OnQueryCloseForm()
FORM.RUNMODAL(50001);

Nun sieht der User nach dem Durchlauf die Fehlerliste und kann selbst entscheiden, ob er dem Prüflauf durch Neustart des Dataports mit gesetzter Import-Option einen realen Import folgen lässt.

Zum Hinweis von Natalie:
Ich habe dem User zum Start des Dataports einen Menüpunkt unter den Debitoren eingerichtet, der Dataport wird nie aus dem Objektdesigner gestartet. Eine explizite Prüfoption ist damit wohl notwendig. Da in einem Importlauf durchaus mehrere Hundert Datensätze eingelesen werden, scheint eine etwas komplexere Vorprüfung angebracht.

Ein schönes WE wünscht Thomas

Zuletzt geändert von Thomas Schulz am 4. Januar 2009 13:08, insgesamt 1-mal geändert.

was verleitet dich zu der Annahme, dass ein Dataport nichts schreibt, wenn er aus dem Object Designer gestartet wird?

Argh, ich hatte mich verschrieben!!!!
Ich meinte, dass dann nichts geschrieben wird, wenn sich der Dataport im Design-Modus befindet und man ihn hieraus mittels Strg+R startet.
Keine Ahnung, wie ich das wieder durcheinander gebracht habe

was verleitet dich zu der Annahme, dass ein Dataport nichts schreibt, wenn er aus dem Object Designer gestartet wird?

Ich meinte, dass dann nichts geschrieben wird, wenn sich der Dataport im Design-Modus befindet und man ihn hieraus mittels Strg+R startet.

Wenn allerdings im Code ein COMMIT z.B. im OnPostDataport-Trigger steht, dann schreibt der Dataport auch im diesem Modus die Daten weg. Bei Dataports, die man nicht selber geschrieben hat, sollte man das immer erst prüfen. Da sind mir schon einige über den Weg gelaufen.

was verleitet dich zu der Annahme, dass ein Dataport nichts schreibt, wenn er aus dem Object Designer gestartet wird?

Ich meinte, dass dann nichts geschrieben wird, wenn sich der Dataport im Design-Modus befindet und man ihn hieraus mittels Strg+R startet.

Ha! Da habe ich auch wieder etwas dazugelernt!

Wenn allerdings im Code ein COMMIT z.B. im OnPostDataport-Trigger steht, dann schreibt der Dataport auch im diesem Modus die Daten weg.

Und noch mehr dazugelernt

Wie gut, dass ich nach Möglichkeit schon immer Im-/Exporte ohne Dataports realisiere, da weiß ich wenigstens, was abläuft.
Dataports haben mir zuviel Eigenleben.