Agent zum ändern von Feldwerten bestimmter Maske: Beispiel gesucht

[reraru]

Guten Morgen,

ich habe noch nie einen Agenten erstellt und beabsichtige folgendes. Über die Suchfunktion bin ich nicht wirklich weiter gekommen.

Ich möchte einen severseitigen Agenten erstellen der alle Dokumente der Maske "Firma" durchsucht und hier nur die Dokumente bearbeitet bei denen das Feld Kundennummer gefüllt ist. Wenn das Feld Kundennummer einen Wert enthält, dann wird dem Feld Umsatz ein Wert zugeordnet.

Ich suche eigentlich ein Beispiel das vergleichbares macht: Dokumente nach bestimmter Maske wählen, Feldwert prüfen und bei positiver Rückmeldung einen anderen Feldwert ändern.

Ehrlich gesagt ist mir egal ob das per Formel oder Script passiert. Könnte mir vorstellen das Script doch etwas besser zu lesen ist.

So etwas hat doch sicher jemand parat..., oder?

Danke im Voraus!

Gruß René

[ata]

... das muß man nicht parat haben, daß ist schneller geschrieben als gesucht und gefunden. Aber du wirst kaum einen finden, der dich hier so einfach mit fertigem Code beliefert - do it yourself - Hilfestellung kannst du jederzeit bekommen... 

Wenn du noch nie einen Agenten erstellt hast, dann solltest du dir die Fundamentals zu Agenten erst mal anschauen. Das kann man mit Lotus Script machen, aber auch mit Formel.

Toni

[Driri]

Soll das eine einmalige Aktion werden ?

Wenn ja, könnte man auch einfach eine private Ansicht erstellen, die nur die Dokumente mit Maske "Firma" und einem Wert im entsprechenden Feld anzeigt.
Der Agent braucht dann ja nur noch den Feldwert zu setzen, da die Auswahl bereits eingeschränkt ist. Das könnte man dann relativ simpel mit einem Formelagenten erledigen.

Ansicht und Agent kann man ja dann anschließend auch wieder löschen.

[ata]

Wenn ja, könnte man auch einfach eine private Ansicht erstellen, die nur die Dokumente mit Maske "Firma" und einem Wert im entsprechenden Feld anzeigt.

Die Suchformel kannst du auch im Agenten verwenden, dann brauchst du keine zusätzliche Ansicht. In der Suchformel geht man auf Maske, und ob das entsprechende Feld nicht leer ist. Dann noch den Wert berechnen und ins Feld schreiben - Fertig...

Toni

[Driri]

Stimmt, das machts noch kürzer. Ich behelfe mir ganz gerne mit der Ansicht, um vorm Lauf des Agenten mal einen Überblick zu haben, um welche Dokumente (und um welche Menge an Dokumenten) es geht.

[ata]

Ich behelfe mir ganz gerne mit der Ansicht, um vorm Lauf des Agenten mal einen Überblick zu haben, um welche Dokumente (und um welche Menge an Dokumenten) es geht.

... da hast du sicher recht - für einen Überblick zu Beginn recht gut, um zu sehen, ob der Select sauber ist. Ansonsten belastet jede Ansicht in der DB auch die Performance und macht es teils unübersichtlich. Daher hätte ich solch eine Ansicht bei komplexen Selects auch drin, würde sie aber bei so einfachen Operationen wie hier wieder aus dem System nehmen...

Toni

[reraru]

Hi,

ich hatte gehofft das jemand vielleicht ein Beispiel hat an dem ich mich orientieren kann.

Der Agent soll hinterher täglich laufen (nachts) und bei den Firmendokumenten mit einer Kundennummer
per ODBC die Umsatzwerte (Jahr, Vorjahr, Vor-Vorjahr) in die entsprechenden Felder schreiben. Das Beschreiben der Felder ist kein Problem.

Ich habe mir das mit den einfachen Aktionen mal angesehen. Bei der Auswahl kann ich "nach Formular" anwählen und auch "nach Beispielmaske" was muss ich denn im Feld eintragen wenn ich nur die Kunden mit Kundennummer rausfiltern will. ">0" klappt scheinbar nicht.

Ich habe mir ja schon Gedanken gemacht. Genauer gesagt ein paar Formeln. Mir fehlt aber noch die Logik.

/ Alle Dokumente des Forms "Kunde" durchlaufen und die Abfrage der Variable "Kunde" /

Bei einem Formelagenten kann ich die Auswahl nur über einfache Aktionen machen, oder?


Hier meine Bausteine:

Code

'Jahre zweistellig zusammenbauen';
JahrJJ:= @Right(@Text(@Year(@Now));2);
VorjahrJJ:= @TextToNumber(JahrJJ)-1;
VVorjahrJJ:= @TextToNumber(JahrJJ)-2;


"Hier müsste wohl ne Schleife hin, oder";

"Kundennummer ermitteln";
Kunde:= @GetField("com_Kundennummer");

@If(@IsNull(Kunde);""; 

"SQL-Strings bilden";

sqlJ:= "SELECT SUM(UXNWEF) AS SUM FROM SRVAS01.ANCRADTA.UMSSTAL1 WHERE UXKDNR = " + @Text(Kunde) + " AND UXERJJ = " + @Text(JahrJJ);
sqlVJ:= "SELECT SUM(UXNWEF) AS SUM FROM SRVAS01.ANCRADTA.UMSSTAL1 WHERE UXKDNR = " + @Text(Kunde) + " AND UXERJJ = " + @Text(VorjahrJJ);
sqlVVJ:= "SELECT SUM(UXNWEF) AS SUM FROM SRVAS01.ANCRADTA.UMSSTAL1 WHERE UXKDNR = " + @Text(Kunde) + " AND UXERJJ = " + @Text(VVorjahrJJ);

"Umsatz ermitteln aktuelles Jahr";
xRes:=@DbCommand("ODBC" ; "DSN" ; "dbreader" ; "dbreader" ; sqlJ);

ergJ := @If(
@IsError(xRes);
     "Keine Berechnung möglich";
     xRes);
ergJ;

@SetField("com_sales_UL"; ergJ);


"Umsatz ermitteln Vorjahr";
xRes:=@DbCommand("ODBC" ; "DSN" ; "dbreader" ; "dbreader" ; sqlVJ);

ergVJ := @If(
@IsError(xRes);
     "Keine Berechnung möglich";
     xRes);
ergVJ;

@SetField("com_sales_UVJ"; ergVJ);


"Umsatz ermitteln Vor-Vorjahr";
xRes:=@DbCommand("ODBC" ; "DSN" ; "dbreader" ; "dbreader" ; sqlVVJ);

ergVVJ := @If(
@IsError(xRes);
     "Keine Berechnung möglich";
     xRes);
ergVVJ;

@SetField("com_sales_UVVJ"; ergVVJ)
);

[Driri]

Also bei etwas komplexeren Themen neige ich persönlich dazu, das dann lieber in Script zu realisieren. Ein fertiges Script wird Dir aber vermutlich niemand hier liefern können.

Ich halte es auch nicht für sonderlich geschickt, jeden Wert einzeln per ODBC-Zugriff abzufragen. Das dürfte aus Performancesicht der schlechteste Weg sein.

Ich muß aber auch gestehen, daß ich noch nie mit direkten ODBC-Zugriffen gearbeitet habe. Entweder machen wir hier solche Dinge über eine Datenpumpe oder ich erhalte die Daten als CSV und lese die Textdatei dann via Script aus.

[Schnubbel]

Hallo René,
ich hab jetzt einfach mal aus meinen Fundus ein bisschen Script kopiert. Evtl. kannst du dich ja daran orientieren. Aber Vorsicht, da ist keinerlei Fehlerroutine drin. Am Ende sind alle Dokumente der Form "Person" in der dc. Hoffe, dass es dir ein wenig hilft.

Code

Dim s As New NotesSession
Dim db As NotesDatabase
Dim dc As Notesdocumentcollection
Dim doc as Notesdocument
set db = s.currentdatabase

Dim Formel As String

Formel = {Form="Person"}

Set dc = db.Search( Formel, Nothing, 0)

[Tode]

Ein gutgemeinter Rat: Du als Programmierer wirst für die Daten die da stehen verantwortlich gemacht werden (eigene Erfahrung)... Und evtl. werden sogar Entscheidungen / der Verlauf von Kundengesprächen von den Inhalten dieser Felder abhängen...

Dein Formel- Agent macht vermutlich (so rein vom drüberfliegen) schon das richtige, aber Du hast keinerlei Logging (wenn ODBC- Zugriffe schief gehen), keinerlei Erfolgsmeldungen und keinerlei Informationen darüber, wie aktuell / korrekt die Werte sind...

Und wehe, Dein Wert weicht nur um wenige Euro von dem ab, was im zugrundeliegenden System steht, dann musst Du Dich rechtfertigen können, was Du mit einer solchen Lösung nicht kannst...

Von Performance / Sicherheit / etc. will ich gar nicht reden.

Du solltest das in LotusScript machen (lassen) und ein anständiges ErrorHandling / Reporting / Logging drumrum machen, sonst schnappt Dir das früher oder später ins Gesicht...

Zur Frage: Du kannst im Formelagenten einfach ein SELECT- Statement vorneweg schreiben, um die Auswahl der Dokumente einzuschränken...

[ata]

... ich versuche "Einfache Aktionen" zu meiden wie der Teufel das Weihwasser   - die Probleme waren immer ausserhalb jeglicher Toleranz.

Dein ursprünglicher Wunsch war:

Ich möchte einen severseitigen Agenten erstellen der alle Dokumente der Maske "Firma" durchsucht und hier nur die Dokumente bearbeitet bei denen das Feld Kundennummer gefüllt ist. Wenn das Feld Kundennummer einen Wert enthält, dann wird dem Feld Umsatz ein Wert zugeordnet.

... von ODBC-Zugriff war keine Rede !

Den Agent kannst du per Formel in der Art ...

Select Form = "Firma" & Kundennummer != ""

... entsprechend filtern lassen.

Bei LS nimmst du den vorgeschlagenen db.Search. Die Formel für den Search wie bereits benannt.
Der Agent muß unbedingt unrestricted sein, da er auf fremde Quellen zugreifen muß.
Der Zugriff über ODBS per LS benötigt auch die notwendigen Treiber im OS. Was für eine relationale DB steht den dagegen?

Also mein Tip - wie Torsten bereits gesagt hat - lasst jemanden ran, der das schon einmal gemacht hat. Ohne Erfahrung zahlt man hier einiges an Lehrgeld  

Toni

[reraru]

Mahlzeit zusammen,

ihr habt natürlich recht mit der Aussage das es wohl am besten in LS zu realisieren ist.
Die Performance kann in diesem Fall vernachlässigt werden, da der Agent Nachts laufen
soll wenn hier alles tot ist. Schön wäre es aber natürlich anders.

Ich hatte auch angedacht bei Fehlern während der Abfragen "kein Wert" anstelle des
Umsatzes anzuzeigen und auch noch ein Feld mit dem Datum der letzten Aktualisierung
einzubauen. Für die Belange hier im Unternehmen ist das ausreichend. Das Ganze dient
nur als zusätzliche Info und direkt daneben kommt auch noch ein Button mit dem ein Fenster
geöffnet wird welches dann online die Umsätze anzeigt.

Das anzapfen der Daten aus der ODBC DB hatte ich aanfangs nicht erwähnt weil dies ja nicht
mein Problem ist. ;-) Quelle der ODBC-Connection ist übrigens eine DB2 vom System i. Treiber
vorhanden.

Ich danke Euch erstmal für die zahlreichen kommtentare. Nach diversen Sitzungen heute raucht
mir gerade der Kopf. Ich werde mir das am Montag noch einmal in Ruhe anschauen.

Euch ein schönes Wochenende!

Gruß René

[ata]

... dir auch ein schönes WE

[smokyly]

Dein Formel- Agent macht vermutlich (so rein vom drüberfliegen) schon das richtige, aber Du hast keinerlei Logging (wenn ODBC- Zugriffe schief gehen), keinerlei Erfolgsmeldungen und keinerlei Informationen darüber, wie aktuell / korrekt die Werte sind...

Und wehe, Dein Wert weicht nur um wenige Euro von dem ab, was im zugrundeliegenden System steht, dann musst Du Dich rechtfertigen können, was Du mit einer solchen Lösung nicht kannst...

Da das Weitergeben von Daten mein Hauptgeschäft ist, kann ich Dir nur sagen, dass mit dem Risiko der Betrieb rechnen muss. Programmierfehler sind eben ab und an programm.

Gruß

[ata]

Da das Weitergeben von Daten mein Hauptgeschäft ist, kann ich Dir nur sagen, dass mit dem Risiko der Betrieb rechnen muss. Programmierfehler sind eben ab und an programm.

... nur das Schlachtfest findet zunächst immer beim Programmierer statt - 

[reraru]

Moin,

wollte nur noch kurz erwähnen das ich Euren Ratschlag befolge und mir die Geschichte von jemandem umsetzen lasse der
dies schon einmal gemacht hat.

Gruß René

[ata]

... ist manchmal der schnellere und effizientere Weg

[klaussal]

... und man lernt noch dabei.