Multi-Mail-Versand

[rrbd]

Hallo,
wegen  http://www.sps-forum.de/sonstige-steuerungen/54557-ilc-150-eth-automatische-fehlermeldung.html dieses Problems  muss ich mir kurzfristig einen FB basteln, der zu grob geschätzt 100 Störmeldungen aus der Anlage, die bei einem Controller vorkommen können, die jeweils passige aus 100 E-Mails abzusetzen. Natürlich können auch mehrere (fast alle) Störungen auf einmal passieren, das muss dann schnell, aber geregelt abgearbeitet werden. Da ein solcher FB eine Ergänzung des SMTP-Client von allgemeinem Interesse sein könnte, will ich meine Überlegungen hier kurz vorstellen, evtl. können meine Experimente die Basis für einen neuen OSCAT-Baustein sein?!


Mailtext-Zuordner
Über einen SMTP_Client sollen alle (100) möglichen Störmeldungen, jeweis mit Summary und Body, abgesetzt werden. Das heißt wenn eine Störung ansteht muss dem SMTP_Client das  richtige Summary â€" Body â€" Paar per Mailzuordner angelegt werden. Die übrigen Eingänge von SMTP-Client (MailTo etc) sind für alle Störungen gleich.
Momentan würde ich einen 2. Client mit gleich aufgebautem Mailzuordner dazustellen, der auf das Service-Smartphone den Kundendienst alarmiert. Hintergrund:,  unwichtige Störungen sollen an diesen Empfänger nicht während der Nacht oder Feierabend durchgestellt werden (also gehen Sie hier an den Mailzuordner nur während einer Kernzeit, Wochenzeitschaltuhr + Feiertagsprogram)

Ins Unreine Gedacht:
Summary1 … Summary100     oscat_string 120   
Body1 … Body100                oscat_string 250
   Lokale Variablen, kann ich leicht erzeugen und Texte in PC WORX hinein kopieren
xStoerung1 … xStoerung100 BOOL    Eingänge für die jeweilige Störung
xReset       Bool   Reseteingang
xStoerAus   Bool   Ausgang Sendestörung   vom Baustein   

Zuordnungs-FB Programm Grobstruktur
...Zählt mit jedem Zyklus ein Index-SINT hoch
...Wenn zum Index Störeingang aktiv:
......Ausgabe der zugehörigen Strings an SMTP_CLIENT
......Client aktivieren (Senden)
......Warten bis „Done“ oder Fehlermeldung
......Bei Fehlermeldung Versuchezähler hochzählen und Wartezeit aktivieren
......Bei "Done" Meldungssperre, Selbsthaltung solange Fehlereingang ansteht
...Index Weiterzählen
......Wenn die Störung mit Sendefehler wieder vom Indexdurchlauf her „dran“ ist,
......erneuter Versuch, wenn Wartezeit abgelaufen
.........Im Erfolgsfall Erfolgsflag (Wiedersendungssperre Siehe oben)
.........Bei 3 Misserfolgen "Mailstörungsflag" als Stoer Boolausgang und Sperre weiterer Sendungen für diese Mail,
......  Rücksetzbar über xReset Booleingang.
...Wenn Index >100 -> Index = 1
...Endlosschleife neu ab „Zählt mit jedem Zyklus ...“
...
Besteht grundsätzliches Interesse, hier Ideen beizusteuern?

Grüße,  Rainer

[rrbd]

Sieht nicht so aus ... .
Ich habe trotzdem mal angefangen. Über die Textzuordnung zu den Stör-Flags mache ich mir später Gedanken, jetzt habe ich mir erst mal eine 3er-Schrittkette, die nach Abschluss der Tests auf die von mir angepeilte Größe von 100 möglichen Meldungen / CPU (keine Prinzipelle Grenze) ausgedehnt werden kann.

Die Schrittketten-Struktur erlaubt bei Verwendung nur eines SMTP_CLIENTs beliebig viele gleichzeitig auftretende Meldungen nacheinander abzuarbeiten und so im Sekundentakt (grob) eine Meldung nach der anderen abzuarbeiten, bis alle Meldungen 'raus sind.

Das funktioniert schon ganz gut.

In der Schrittkette sind Instanzen des immer selben Funktionsbaustein aneinandergereiht. Erscheint die Notwendigkeit einer E-Mail-Sendung (Sammelstörung) wird der 1. Funktionsbaustein (1. Schritt) mit einem Zyklus-Impuls angetriggert.
a: Der Baustein überprüft, ob seine Aktivierungseingang auf 1 gesetzt ist ("Seine" Störung aktiv ist.
   Wenn nicht, triggert er sofort den nächsten Schritt per Impus an.
b: Wenn doch, überprüft der Baustein, ob "Seine" Meldung bereits erfolgreich gesendet wurde.
    Wenn ja,  triggert er (auch) sofort den nächsten Schritt per Impus an.
c: wenn nicht, gibt er "Seine" Störungsnummer 'raus, die dann aus 2 String-Arrays Body und Subject für
    SMTP_CLIENT zuordnet.
    Eine Störungsnummer <> 0 aktiviert SMTP_CLIENT für Störungsversand
d: Schrittkette bleibt so lange in diesem schritt, bis "Done" vom SMTP_CLIENT
e: Der FB für diesen Schritt speichert den erfolgreichen Versand, solange Störmeldung ansteht (für 'b')
f: FB triggert nächsten Schritt an, Dieser erledigt 'a' ... 'f' für "Seine" Störumeldung.

Der letzte Baustein in der Reihe gibt wieder einen Start-Trigger-Impuls an den ersten Schritt, der wieder
'a' ... 'f' durchführt, die Schrittkette wird wieder abgearbeitet, wenn sich eine Störmeldung erledigt hat wird die Speicherung von 'e' im entsprechenden Baustein zurück gesetzt, wenn eine neue Störung aufkam, verschickt der zugehörige Baustein seine Meldung.

Geht  SMTP_CLIENT auf "Error" veranlasst die Beschaltung alle x (5) Minuten einen Sendeversuch, die Schrittkette verharrt in diesem schritt bis die Mail erfolgreich abgesetzt wurde. Das ist ein Risikofaktor, was, wenn die Störung beispielsweise durch einen fehlerhaften String (unzulässiges Zeichen) für diesen Schritt verursacht wurde? Dann ist der Mailversand tot, das muss ich überdenken.
 
Gerade fiel mir auch auf, dass der Kreislauf weiter geht, auch wenn keine Sammelstörmeldung mehr ansteht, das heißt bei nächster Störung haben wir 2 aktive Bausteine in der Kette, das darf nicht sein, muss ich unterbinden.

So teste ich gerade alle Eventualitäten, die mir einfallen, es wäre toll, wenn jemand mit macht, und vielleicht auch Ideen kommen, wie man meine  "Testschaltung" in eine elegante OSCAT Lösung umwandeln könnte. Programm (Phoenix) stelle ich bei Interesse gern zum Download bereit.

Grüße

Rainer

[rrbd]

So, das funktioniert, woweit ich das sehen kann, zunächst schon mal fehlerfrei. Die Notwendigkeit, den Handhabungs-FB für jede denkbare Meldung im Programm haben zu müssen ist ja doch sehr hässlich. Das Ziel ist, dass der FB eine Struktur mit folgenden Elementen verwaltet

BODY[Nr].String(250)    für Mail-Body,   Fix-Werte (Texte als Initialisierungwerte)
BODY[Nr].String(80)      für Mail-Body,   Fix-wert
SENT[Nr].BOOL             Flag für erfolgreichen Mail-Versand, wird gesetzt nach "Done" zur mail, rückgesetzt
                                   wenn entsprechende (Stör-) Meldung nicht mehr ansteht
ERROR[Nr].BOOL          Ist einfach das Flag, das mit einer Störmeldung gesetzt wird und anzeigt, dass     
                                   zu eben dieser Störungsnummer der Fehler gerade ansteht, wird nicht vom
                                   FB bearbeitet

Grob-Funktion weiter wir in vorigem Kommentar beschrieben, nur dass nun statt des Schrittketendurchlaufs der Index "Nr" passig zum Geschehen hochgezählt wird:

a: bei Auftauchen der ersten Meldung "Nr" hochzählen, bis zugehöriges ERROR[Nr] gesetzt ist
b ... d: Sinngemäß wie gehabt
e: SENT[Nr] für diese Störmeldung wird gesetzt
f: Nr := Nr + 1
g: Wenn Nr = 100 Nr := 0
    Erneuter Durchlauf für Nr=0 to Nr = 100, solange noch irgendeine Störmeldung ansteht.

Ist eigentlich nicht allzu kompliziert.

Rainer

[rrbd]

So, ich habe heute mal wieder mein Hobby weiter verfolgt, und wie angekündigt den Meldungs-Handler so abgewandelt, dass nur noch einer benötigt wird, um eine große Anzahl verschiedener Emails (wenn es sein muss, auch im Rahmen der Arbeitsgeschweindigkeit des SMTP_CLIENT quasi "auf einen Schlag") abzusetzen. Meine 3er-Test-Anordnung funktioniert, der neue Baustein führt dem SMTP_CLIENT für gleichzeitig ausgelöste E-Mails der Reihe nach alle Texte zu und veranlasst den sequentiellen Versand. Ich will noch ein paar weitere Tests mit dieser übersichtlichen Anzahl machen, dann teste ich den vollständigen geplanten Ausbau mit bis zu 100 Meldungen.

Das sollte mit einer ILC 130 funktionieren, während bei simpler Verwendung von je einem SMTP_CLIENT je Meldetext schon bei 3-4 verschiedenen Meldungen Schluss ist, da jeder grob 30 KB (habe die genaue Zahl nicht mehr im Kopf) Speicher belegt, und etwas Anwendungsprogramm muss ja auch noch 'rein passen

Gruß

Rainer

[rrbd]

So, habe gestern jede Menge Tests durchgeführt, funktioniert, schön.

Damit ist die Limitierung auf 2-4 Mails bei den Phoenix ILC 1xx (Speicherbedarf) erledigt. Falls jemand Lust hat, darüber nachzudenken, das in eine professionelle OSCAT-Form zu bringen:

• Beschreibung ist angehängt
• Demoprogramm MailVorrang_30O.zwe hier http://www.bielefeldundbuss.de/OSCAT/MailVorrang_30O.zwe

Gruß

Rainer

[gelöscht durch Administrator]