eMail - Variablen / Felder auslesen zur Regelverwendung?

JürgenJester · 22. Juni 2011

Hallo Leute,

ich stolpere andauernd über meine eigenen Ansätze. Kann mir vielleicht jemand sagen, wie ich es schaffen kann, in eMails nach Inhalten zu suchen um diese in Regeln zu nutzen. Beipielsweise - ich stelle in einer "Bedingung" im Regelwerk fest woher eine Mail kommt. Dann würde ich gerne über einen 'Regulären Ausdruck' einen Bereich von sagen wir mal 5 Zahlen lokalisieren ( OrderID:[0-9]{5} ) und diese 5 Zahlen in ein Benutzerdefiniertes Feld bekommen. Doch wie schon versucht, bekomme ich in angelegte 'Benutzerdefinierte Felder' keine Werte rein, außer ich nagel einen Audruck direkt rein - dynamisch füllt sich da leider nichts. Versteht mich und mein Problem hier jemand?

Viele Grüße,
der Jürgen

oliver@GREYHOUND · 22. Juni 2011

Hallo,

eine automatische Übernahme von Daten aus dem Text in Benutzerdefinierte Felder gibt es derzeit nicht. Das heißt die Inhalte müssen selbst transferiert werden. Die Werte können ja auf vielfältige Weise beschafft werden. Die Extraktion per RegEx ist ja nur eine Variante, die theoretisch möglich ist.

jörn@GREYHOUND · 22. Juni 2011

Hallo Jürgen,

anbei mal ein kleines Beispiel, wie man das per Regex lösen kann:

Szenario: Eingehende Faxe werden per OCR texterkannt, aus dem Fließtext soll alles der Zeile nach einem bestimmten String in ein benutzerdefiniertes Feld geschrieben werden. Hierzu kann man eine entsprechende Regel anlegen, welche über einen Quelltextknoten zum Beispiel folgendes ausführt:

Code

try
if Item.UserFields.Exists('Ort') then
Item.UserFields.ItemsByName['Ort'].AsString := FbmRegExExtract(Item.TextViewData, '([0O]RT[5S]TEIL/[0O]RT ?: )\s*([0-9a-zA-Z -/ßäöüú,.;:_]+)','$2', '');
except
end;

Der Quelltext prüft ab, ob das benutzerdefinierte Feld existiert und schreibt wenn vorhanden alles nach dem String "ORTSTEIL/ORT: " in das entsprechende benutzerdefinierte Feld.

Für den Elementtyp "E-Mail" geht das natürlich genauso.

JürgenJester · 23. Juni 2011

Hallo und vielen Dank für den Workaround - jetzt gehts hier schonmal weiter, das bietet ja wieder ganz neue Wege die man gehen kann, herzlichen Dank dafür.

Viele Grüße,
Jürgen

Timo · 23. Juni 2011

Endlich bekommen wir aus den gescannten Dokumenten Lieferscheinnr., Rechnungsnr. usw. vollautomatisch in die Betreffzeile! *freu*

Für alle die eine ähnliche Regel nachbauen möchten, habe ich einmal eine Beispielregel im Expertenmodus erstellt und hier angehängt!

Nochmals vielen Dank an Sascha & Jörn für die klasse Beiträge hier!

Gruß Timo

ODT1 · 1. Juli 2011

@Jörn,

das funktioniert super, ich würde allerdings gerne ein kleines Stück weiter gehen bzw. einen anderen Weg wählen:

Diese Vorgehensweise funktioniert ja nur, wenn ich im Text nach einem eindeutigen Textteil suchen kann. Was ich machen möchte ist, nach der Kontaktklassifizierung aus dem Benutzerdefinierten Feld des Kontaktes den Inhalt in ein Benutzerdefiniertes Feld schreiben, welches im Brief, Mail, etc. zur Verfügung steht.

bzw. wie kann ich vom Kontakt das benutzerdefinierte Feld Kundennummer auch in den Listen verfügbar machen?

Ist dies machbar?

Wolfram · 1. Juli 2011

ODT1 schrieb:

Was ich machen möchte ist, nach der Kontaktklassifizierung aus dem Benutzerdefinierten Feld des Kontaktes den Inhalt in ein Benutzerdefiniertes Feld schreiben, welches im Brief, Mail, etc. zur Verfügung steht.

Ich habe mal eine Regel geschrieben (oder habe ich die mehr oder weniger aus der Doku übernommen?), die nach erfolgreicher Kontaktklassifizierung das "Thema" des Kontakts für die Nachricht übernimmt. In der Art könnte es für Benutzerdefinierte Felder auch gehen:

Code

var
ContactItem: TFbmItem;
begin
if (Item.ClassifiedCount > 0) then
begin
ContactItem := TFbmItem.Create(ikEmail, 0);
try
ContactItem.DbQuery := Item.DbQuery;
ContactItem.Load(Item.Classified[0]);
Item.TopicRef := ContactItem.TopicRef;
finally
ContactItem.Free;
end;
end;
end.

Alles anzeigen

Ich hoffe, das wird jetzt nicht zu sehr off-topic.

ODT1 · 1. Juli 2011

Wolfram ,

vielen lieben Dank!

Code

var
ContactItem: TFbmItem;
begin
if (Item.ClassifiedCount > 0) then
begin
ContactItem := TFbmItem.Create(ikEmail, 0);
ContactItem := TFbmItem.Create(ikLetter, 0);
ContactItem := TFbmItem.Create(ikFax, 0);
try
ContactItem.DbQuery := Item.DbQuery;
ContactItem.Load(Item.Classified[0]);
Item.UserFields.ItemsByName['KDNR'].AsString := ContactItem.UserFields.ItemsByName['Kundennummer'].AsString;
finally
ContactItem.Free;
end;
end;
end.

Alles anzeigen

oliver@GREYHOUND · 1. Juli 2011

Hallo,

dreimal TFbmItem.Create und alles in eine Variable geht so nicht. Jede Variable darf immer nur ein Objekt halten und muss jeweils mit .Free erst wieder freigegeben werden, bevor du das nächste mal mit .Create wieder eine Objektinstanz reinpackst. Dreimal ein TFbmItem Objekt zu erzeugen ist aber auch unnötig an dieser Stelle...

ODT1 · 1. Juli 2011

Servus Oliver,

besten Dank für den Hinweis, hab ich sogar Verstanden was Du meinst... Nur weiß ich nicht wie ich aus den dreien einen mache... Sprich das ganze soll für Brief, Mail und Fax gelten... Klar könnte ich drei verschiedene Regeln bauen, aber ich glaube das wäre auch unnötig?

ODT1 · 1. Juli 2011

dg_og schrieb:

dreimal TFbmItem.Create und alles in eine Variable geht so nicht.

achso, funktioniert aber

oliver@GREYHOUND · 1. Juli 2011

Hallo,

ja, gibt aber Memory Leaks, das heißt der Speicherverbrauch von GREYHOUND steigt bei jedem Regeldurchlauf. Was nicht ganz so Ideal ist.

ODT1 · 1. Juli 2011

Das glaube ich gerne habe noch ein wenig rumprobiert, bekomme aber das ganze nicht einfacher hin, sprich die drei

ContactItem := TFbmItem.Create(ikEmail, 0);
ContactItem := TFbmItem.Create(ikLetter, 0);
ContactItem := TFbmItem.Create(ikFax, 0);

brauche ich aktuell da es sonst immer nur für ein Element geht...

oliver@GREYHOUND · 1. Juli 2011

Hallo,

verstehe ich jetzt nicht. Das ContactItem wird mit Load später sowieso geladen. Der übergebene "Kind" beim Create wird also überhaupt nicht berücksichtigt. Das hat keine Auswirkung auf den berücksichtigten Element-Typ (E-Mail, Fax, Brief).

Die Zeile für die Übernahme des benutzerdefinierten Feldes würde ich ggf. sicherheitshalber noch absichern, falls dieses im Ursprungselement ungültig ist:

Code

try
Item.UserFields.ItemsByName['KDNR'].AsString := ContactItem.UserFields.ItemsByName['Kundennummer'].AsString;
except
Item.AddToProtocol('Die Kundennummer aus dem klassifizierten Kontakt konnte nicht übernommen werden.');
end;

ODT1 · 1. Juli 2011

Besten dank für den Versuch mir das zu erklären, aber ich verstehs nicht Mir fehlt da aktuell das Wissen welches Du hast - in Bezug auf das du genau weißt was wann wo passiert oder passieren muss da du es entwickelt hast

Muss ich mir irgendwann mal in Ruhe anschauen...

oliver@GREYHOUND · 1. Juli 2011

Hallo,

ich versuchs mal mit einer riesen Kanne voll Wasser und einem Glas.

Nehmen wir an

ContactItem := TFbmItem.Create(ikEmail, 0);

entspricht

Glas Wasser = Bis zum Rand voll

---

ContactItem.Free;

entspricht

Wasser in den Ausguss = Ordentlich entsorgt.

---

Füllst du nun dein Glas Wasser, wenn es bereits voll ist, läuft dir das Wasser auf den Tisch, und niemand macht es weg. Also enspricht:

Wasser auf dem Tisch = Memory Leak.

Wenn du das oft genug machst, steht der Raum vollständig unter Wasser und du hast keine Luft zum Atmen mehr.

Wünsch dir ein schönes Wochenende.

ODT1 · 1. Juli 2011

Merci, das habe ich verstanden aber...

wenn ich den bereich

ContactItem := TFbmItem.Create(ikEmail, 0);
ContactItem := TFbmItem.Create(ikLetter, 0);
ContactItem := TFbmItem.Create(ikFax, 0);

und
finally
ContactItem.Free;

entferne, macht er nicht mehr das was er will... sprich da hängts bei mir irgendwo, sprich ich habe das:

"Dreimal ein TFbmItem Objekt zu erzeugen ist aber auch unnötig an dieser Stelle... "

nicht verstanden...

oliver@GREYHOUND · 4. Juli 2011

Hallo,

einfach das:

Code

ContactItem := TFbmItem.Create(ikEmail, 0);
ContactItem := TFbmItem.Create(ikLetter, 0);
ContactItem := TFbmItem.Create(ikFax, 0);

durch das ersetzen:

Code

ContactItem := TFbmItem.Create(ikEmail, 0);

Sonst stimmt alles. Du hast nur zwei Objekte zuviel.

jörn@GREYHOUND · 4. Juli 2011

Ich versuch's mal bildhaft mit einem Augenzwinkern zu erklären:

1.) Du hast 3 Bierflaschen, je ein Apfeltranger, Irseer Klosterbräu Maibock und ein Meckatzer (3x Create Item), welche du zusammen in einen Halbe-Krug (Regel) schütten willst.

Problem:

1.) Helles, Maibock und Weissbier zusammenschütten schmeckt nicht.
2.) Der Halbe-Krug ist für 3 Flaschen Bier einfach zu klein, das Ding läuft über und schäumt. (Memory Leak)

Lösung: Nimm für jede Halbe (Create Item) nen eigenen Krug (Regel), dann klappt's auch, nix wird verschüttet und es schmeckt noch!

Prost!

ODT1 · 4. Juli 2011

@Jörn,

ich lasse mir lieber jedes für sich schmecken und machen dann also drei Regeln draus, merci Kommt halt immer auf die Sprache an die man versteht, gell

@Oliver,

merci, so war sie ja am Anfang und ich wollte es vermeiden, drei Regeln zu bauen, aber so werde ich diese Elementgesteuert einzeln abarbeiten lassen.

Perfekt wäre es halt nur noch, wenn man bei einem Filter ein benutzerdefiniertes Feld berücksichtigen lassen kann, mit Themen und Kennzeichnungen klappt es nicht so ganz, zumindest habe ich da noch keine Lösung -> eventuell etwas für die Featurewunschlistewennestechnischmachbarist

Tags