Eine neue Version der Dataflow Workbench dWb+ ist verfügbar! Nach der an dieser Stelle bereits veröffentlichten Ankündigung einer größeren Überarbeitung ist das dort bereits erwähnte neue Feature nunmehr fertig gestellt.
Das System dWb+ erlaubt die Verbindung zwischen Aus- und Eingängen nur dann, wenn der Ausgang Botschaften eines Typs erzeugt, die der jeweilige Eingang verarbeiten kann. Dabei müssen die Typen von Aus- und Eingang nicht exakt aufeinander passen - das lässt sich vielleicht am besten an einem Beispiel erläutern: Ein Ausgang, der ganze Zahlen erzeugt, kann mit einem Eingang verbunden werden, der Zahlen entgegennimmt, da auch ganze Zahlen Zahlen sind. Umgekehrt ist es aber nicht möglich, einen Ausgang, der Zahlen erzeugt mit einem Eingang zu verbinden, der nur ganze Zahlen erwartet. Denn die Ausgangsspezifikation allgemeiner Zahlen könnte auch gebrochene Zahlen einschließen, mit denen der Eingang aber nicht umgehen könnte.
Seit Version 4.3pre1 ist es möglich, Ein- und Ausgänge, deren Typen eigentlich nicht zueinander passen dennoch zu verbinden: Hält man während des Drag'n'Drop die Taste Strg gedrückt, ist die im vorhergehenden Absatz beschriebene Validierung zueinander passender Datentypen von Ein- und Ausgängen außer Kraft gesetzt: Wenn nach Loslassen der Maustaste festgestellt wird, dass die beiden verbundenen Slots nicht zueinander passen, wird zwischen beiden autimatisch ein Konvertermodul in die neue Verbindung eingefügt. Es öffnet sich sofort das Parameterfenster dieses Moduls, in dem der Anwender mittels BeanShell die Konversion des Datenobjekts aus dem Ausgang in ein für den Eingang passendes Objekt spezifizieren kann. Dabei gelten die folgenden Konventionen: In dem BeanShell-Fragment sind zwei Variablen mit besonderen Bedeutungen reserviert: _input hält den vom Quellmodul über den Ausgang versendeten Wert und der am Ende der Ausführung des BeanShell-Fragments in _output gespeicherte Wert wird an den Eingang des Zielmoduls gesendet. Der _input wird ungefiltert in das BeanShell-Fragment übergeben - daher ist es angeraten, null explizit zu behandeln! Um die Arbeit einfacher zu gestalten ist es möglich, für Paare von Datentypen Default-Konversionen zu hinterlegen, die dann automatisch im Editor des Parameterfensters als Vorbelegung auftauchen. Das folgende Beispiel zeigt eine solche Datei:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE properties SYSTEM "http://java.sun.com/dtd/properties.dtd">
<properties>
<comment>Default conversion rules for automatically
inserted BeanShellConversionModules</comment>
<entry key="java.lang.Boolean::java.lang.Number">
_output_=_input_!=null?(_input_.booleanValue()?1:0):null;
</entry>
<entry
key="de.netsysit.dataflowframework.modules.common.ClockTypes::java.lang.Number">
_output_=null;
if(_input_!=null)
{
switch(_input_)
{
case CLOCK: _output_=1;break;
case POSITIVE_SPKIE: _output_=2;break;
case NEGATIVE_SPKIE: _output_=3;break;
default: _output_=0;
}
}
</entry>
<entry key="java.lang.Number::java.util.Date">
_output_=_input_!=null?new java.util.Date(_input_.longValue()):null;
</entry>
<entry key="java.lang.Integer::java.util.Calendar">_output_=null;
if(_input_!=null)
{
_output_ = Calendar.getInstance();
_output_.setTimeInMillis(_input_.longValue());
}</entry>
</properties>
Wichtig ist hierbei noch zu erwähnen, dass die Schlüssel aus dem voll qualifizierten Namen der Klassentypen des Aus- und des Eingangs verbunden durch "::" gebildet werden. Der Schlüssel muss nicht genau passen - beim Typen des Ausgangs besteht Spielraum - es wäre etwa möglich, eine Konversion für den Ausgangstypen java.lang.Number zu spezifizieren - diese würde (sofern der Typ des Eingangs passt) auch dann benutzt, wenn der Ausgangstyp java.lang.Integer ist, es aber für diesen und den jeweiligen Ausgangstyp keine explizite Konversion gibt. In der oben angegebenen Konfiguration wäre die Konversion unter dem Schlüssel java.lang.Number::java.util.Date ein Beispiel dafür.
Natürlich wurde das Handbuch entsprechend erweitert und angepasst.
Alarmierung über Skripte
16.09.2019
Nachdem ich mich in letzter Zeit wieder verstärkt mit den Themen Monitoring und Alarmierung auseinandersetze, habe ich überlegt, ob ich die dabei gewonnenen Erkenntnisse nicht auch dazu nutzen könnte, die bestehende Lösung flexibler zu machen
Weiterlesen...Android Basteln C und C++ Chaos Datenbanken Docker dWb+ ESP Wifi Garten Geo Git(lab|hub) Go GUI Gui Hardware Java Jupyter Komponenten Links Linux Markdown Markup Music Numerik PKI-X.509-CA Python QBrowser Rants Raspi Revisited Security Software-Test sQLshell TeleGrafana Verschiedenes Video Virtualisierung Windows Upcoming...
Das Konzept eines CircuitBreaker ist schon lange bekannt. Ich habe mir zu Studienzwecken einen selber gebaut - eigentlich zwei: Einer ist dafür da, das Logging von gleichartigen Exceptions zu drosseln, der andere für das Entzerren von Versuchen, Ressourcen von URLs nachzuladen. Diese spezielle Variante benötigte ich für EBMap4D: Falls einer der Tile-Server ausfällt, wird ansonsten ständig versucht, die Kacheln neu herunterzuladen. Das frisst nicht nur Rechenzeit, sondern ist auch unnütz.
Weiterlesen...Nachdem ich mich nun schon so lange mit Origami beschäftige habe ich endlich einmal das älteste dokumentierte Ornament versucht - aus gutem Grund...
Weiterlesen...Eine neue Musikreihe/Show auf Youtube gefunden...
Weiterlesen...Manche nennen es Blog, manche Web-Seite - ich schreibe hier hin und wieder über meine Erlebnisse, Rückschläge und Erleuchtungen bei meinen Hobbies.
Wer daran teilhaben und eventuell sogar davon profitieren möchte, muß damit leben, daß ich hin und wieder kleine Ausflüge in Bereiche mache, die nichts mit IT, Administration oder Softwareentwicklung zu tun haben.
Ich wünsche allen Lesern viel Spaß und hin und wieder einen kleinen AHA!-Effekt...
PS: Meine öffentlichen GitHub-Repositories findet man hier - meine öffentlichen GitLab-Repositories finden sich dagegen hier.