Wird also aus einer Steuerkanzlei eine E-Mail an einen Mandanten versendet, erhält dieser nicht mehr den originalen Inhalt sondern eine verschlüsselte Form. Der Inhalt liegt verschlüsselt in der Datei „secure-email.html“ vor.

Um die Email zu lesen, wird die HTML Datei geöffnet. Bei erster Verwendung muss an dieser Stelle ein Account angelegt werden. Von diesem Webportal aus, kann dann auch verschlüsselt geantwortet werden. Antwortet man dagegen aus Outlook heraus auf die E-Mail, ist der eigene Text auf dem Weg zum Datev Server nicht geschützt und nur Transport-verschlüsselt!

Soweit so einfach. Positiv ist, dass nun die Verschlüsselung für jedermann umgesetzt ist. Für viele Nachrichten pro Tag ist das Prozedere dann aber zu aufwendig und unübersichtlich – immerhin landen die eigenen Antworten die aus dem Webportal versendet werden nicht mehr im eigenen Sent-Ordner.

Secure-Mail Anhang durch S-MIME Verschlüsselung ersetzen

Um zukünftig keine Anhänge mehr im Webportal öffnen zu müssen, benötigt es auf der Sender-Seite (z.B. Ihr Steuerberater) Ihren eigenen öffentlichen Schlüssel. Da nun aber der Datev-Mail Server die Verschlüsselung übernimmt, ist es nicht notwendig jedem Sender das Zertifikat aufzudrängen, es wird einfach an zentraler Positon hinterlegt.

Nach erfolgter Anmeldung am Webportal kann nun unter Schlüsselverwaltung ein eigener S-MIME oder PGP Schlüssel hinterlegt werden.
Sobald das Zertifikat hier hochgeladen ist , erhält man „normal“ verschlüsselte E-Mails. Läuft das Zertifikat ab, erhält man wieder den erwähnten Anhang.

Adressaten-Zertifikate erhalten

Mit dem letzten Absatz ist nun sichergestellt, dass alle empfangenen Nachrichten normal verschlüsselt sind. Bleibt die Frage wie man eigene Nachrichten verschlüsselt versendet.

I.d.R. erhält man dazu eine signierte E-Mail, erhält damit den Schlüssel und ist bereit. Die E-Mails von Datev sind aber nicht signiert. Woher also den öffentlichen Schlüssel des Adressaten erhalten?

Dafür lassen sich alle Zertifikate an zentraler Stelle abrufen. Unter „Persönliche Angaben“ ist dabei die E-Mail Adresses des Empfängers, z.B. mitarbeiter1@steuerberater-musterstadt.xy , anzugeben.

Nach dem Download kann das Zertifikat dem Outlook Kontakt zugeordnet werden und ist ab dann zum verschlüsselten Versand verfügbar.

Auch wenn diese Anleitung nicht so direkt auf der Datev-Website zu finden ist, kann man sich die verschlüsselte Kommunikation doch sauber einrichten.

Syntax eines einfachen Copy Into Befehls:

COPY INTO MyTable(Column01, Column02, Column03)
FROM (
SELECT $1, $2, $3 
FROM '@MyStage/folder01'
) 
FILE_FORMAT = CSVFILEFORMAT
PATTERN= '.*\.csv$' ;  

Die Syntax für die Verwendung in einem Select ist ähnlich, aber dann doch wenig intuitiv:

SELECT $1, $2, $3 FROM '@MyStage/folder01'         (         --FILE_FORMAT =>  CSVFILEFORMAT, --falsch         FILE_FORMAT =>  'CSVFILEFORMAT', --richtig         PATTERN => '.*\.csv         ) 

Cheat-Sheet:

• Angaben zum File Format, Pattern etc stehen nun in Klammern nach dem FROM
• Die „=“ werden zu „=>“
• Die Zeilen müssen durch Kommas getrennt werden
• Das FileFormat muss nun in Hochkommas stehen.

Wer diesen letzten Punkt ignoriert erhält die verwirrende Fehlermeldung

SQL-Fehler [2003] [02000]: SQL compilation error:
File format 'CSVDATEN' does not exist.

SELECT metadata$filename, T.$1, T.$2, T.$3
FROM '@~/data' 
(
FileFormat => 'Db.kjeperti.CSV',
Pattern => ".*/[0-9]{8}.csv.gz$"
) t

Die Fehlermeldung ist dabei leider gar nicht hilfreich:

Unsupported feature ‘Table’

SELECT metadata$filename, T.$1, T.$2, T.$3
FROM '@~/data' 
(
File_Format => 'Db.kjeperti.CSV',
Pattern => ".*/[0-9]{8}.csv.gz$"
) t

Im richtigen SQL ist der Tippfehler bei „File_Format“ korrigiert. Es hat der „_“ gefehlt.

Ideal wäre es wenn das natürlich ganz ohne Änderungen am Code oder der Dokumentation abläuft und man nicht noch mehr syntatktische Regeln beachten muss.

WARNING: Block quote ends without a blank line; unexpected unindent.

Diese Fehlermeldung sagt allerdings etwas anderes. Dies ist ein Warning das Sphinx beim Kommando „make html“ ausgespuckt hat.

Ursache dafür war dieser Docstring mit Einrückungen:

def dummyfunction():

'''Das ist ein langer Kommentar mit mehreren Punkten:

   - Punkt1 : Lorem ipsum
     dolor il

   - Punkt2: ....

'''

....

Die Funktionen Replace oder Translate bieten sich an, scheitern aber daran, dass eine Negativliste (also alle Zeichen die man entfernen möchte) erwarten – ziemlich unpraktisch bei UTF8. Ein regulärer Ausdruck könnte auch helfen, ist aber (auch mit Hinblick auf die Performance) mit Kanonen auf Spatzen geschossen.

Die Kombination aus zwei Translate Befehlen arbeitet mit einer Positivliste. Man gibt also eine Liste erlaubter Zeichen an.

Im folgenden Beispiel soll aus einer Strassenangabe nur der Hausnummernanteil gefiltert werden. Die Positivliste sind hier die Zahlen von 0-9.

 
 with input as 
 (
 select 'Hauptstrasse 35a' hausnummer from dual
 )
 select translate(hausnummer,'x'||translate(hausnummer,'0123456789','X'),'x') from input
 --ergibt : 35
 
 

Hier der Link zu einer Demo.

Ich möchte hier das Beispiel der Dokumentation aufgreifen.
Von einer Basisklasse „Employee“ werden zwei weitere Klassen „Manager“ und „Engineer“ abgeleitet.

Grundsätzlich gibt es verschiedene Strategien Klassenhirarchien abzubilden

• Joined Table Inheritance:
  Bei dieser Variante gibt es für jede Klasse eine eigene Tabelle. Die beiden Subklassen erhalten eigene Tabellen mit Referenzen auf die Basisklasse.
• Single Table Inheritance:
  In dieser Form wird die ganze Klassenhierarchie in einer einzelnen Tabelle abgebildet. Aus Blick des Python Codes ist alles sauber. In der Datenbank gibt es aber in der Tabelle Felder, die nur abhängig vom Typ befüllt werden dürfen. Echte Datenbank-Constraints sind damit fast unmöglich.
• Concrete Table Inheritance:
  Hier gibt es auch wieder für jede Klasse eine Tabelle. Diesesmal haben die Subklassen aber keine Foreign Key Beziehung mit der Basisklasse. Jede Tabelle dupliziert auch die Spalten der Basisklasse. Aus Sicht der Datenbank gibt es nun keine Zentrale Tabelle mehr in der alle „Employees“ erfasst sind. Es lässt sich damit auch kein Foreign Key Constraint mehr setzen.

Um ein sauberes Datenbankmodell zu erhalten, ist somit nur die „Joined Table Inheritance“ zu empfehlen:

• Auf Spaltenebene können ohne Problem Check-Constraints und Not-Null-Constraints definiert werden.
• Auch ohne die Kenntnis des SQLALchemy Mappings ergibt sich für andere Anwendungen ganz automatisch welche Felder für welche Klasse gefüllt werden können.
• Die Basisklasse kann durch andere Tabellen via Foreign Key Constraint referenziert werden.

Wie wird nun eine Joined Table Inheritance in Python gemappt?

class Employee(Base):
    __tablename__ = 'employee'
    Id = Column(Integer
                , primary_key=True)
    Name = Column(String(50))

class Manager(Employee):
    __tablename__ = 'manager'
    Id = Column(Integer
                , ForeignKey(Employee.Id)
                , primary_key=True)
    ManagerStatus = Column(String(50))

    __mapper_args__ = {
        'polymorphic_identity': 'manager',
    }

class Engineer(Employee):
    __tablename__ = 'engineer'
    Id = Column(Integer
                , ForeignKey(Employee.Id)
                , primary_key=True)

    EngineerDegree= Column(String(50))

    __mapper_args__ = {
        'polymorphic_identity': 'engineer',
    }

Daraus lassen sich diese Create-Statements generieren.

create_engine('sqlite:///', echo= True)
Base.metadata.create_all(bind=engine)

CREATE TABLE employee (
	"Id" INTEGER NOT NULL, 
	"Name" VARCHAR(50), --Felder der Basisklasse sind hier  ...
	PRIMARY KEY ("Id")
);
-- und werden in den abgeleiteten Tabelle nicht mehr wiederholt
CREATE TABLE engineer (
	"Id" INTEGER NOT NULL, 
	"EngineerDegree" VARCHAR(50), 
	PRIMARY KEY (id), 
	FOREIGN KEY(id) REFERENCES employee ("Id")
);

CREATE TABLE manager (
	"Id" INTEGER NOT NULL, 
	"ManagerStatus" VARCHAR(50), 
	PRIMARY KEY (id), 
	FOREIGN KEY(id) REFERENCES employee ("Id")
);

Wichtig ist dabei der Fremdschlüssel in den abgeleiteten Klassen, der auf die Basisklasse zeigt:

#Employee.Id bezieht sich dabei auf den Klassen/Attributnamen,
#nicht etwa auf Tabellen oder Spaltenbezeichnungen
Id = Column(Integer,ForeignKey(Employee.Id), primary_key=True)

Vergisst man diesen Fremdschlüssel erhält man folgende Meldung:

  Can’t find any foreign key relationships between ‚employee‘ and ‚manager‘.

Das Bayrische Landesamt für Datenschutzaufsicht hat auf ihrer Website eine Todo-Liste speziell für einzelne Branchen online gestellt.

https://www.lda.bayern.de/de/kleine-unternehmen.html

Änderungen am Code werden also erst an das lokale Repository und dann an ein entferntes verteilt. Deswegen sind auch die Begrifflichkeiten für SVN-Umsteiger erst verwirrend.

Wichtige GIT-Begriffe im Schnellcheck:

• clone
  Kopieren/checkout eines entfernten Repositories (komplettes Repository wird kopiert)
• add
  Dateien der GIT-Verwaltung im lokalen Repository hinzufügen.
• commit
  Änderungen an Dateien im lokalen Repository festschreiben.
• push
  Die Commits des eigenen Repositories in ein entferntes Repository schreiben. Im SVN-Jargon ist dies ein „commit“.
• pull
  Update des lokalen Repositories mit Änderungen aus dem entfernten Repo (fetch+ merge). Im SVN-Jargon ist dies ein „update“.
• fetch
  Nur Download der Änderungen, kein automatischer Merge
• merge
  Zusammenführen verschiedener Zweige (zb. Änderungen aus entferntem Repo mit eigenen Änderungen)
• stash
  temporäres, lokales Speichern eines Arbeitsstandes (wichtig z.B. vor Pull mit Änderungen an eigenen Dateien)

Links:

Walkthrough: https://rogerdudler.github.io/git-guide/index.de.html
Best Practises: http://sethrobertson.github.io/GitBestPractices/
Stashes: http://de.gitready.com/beginner/2009/01/10/stashing-your-changes.html
Grafischer Client: https://git-scm.com/download/win + https://tortoisegit.org/

strPattern = "^([a-zA-Z0-9_\-\.]+)@[a-z0-9-]+(\.[a-z0-9-]+)*(\.[a-z]{2,3})$"

In diesem Blogpost geht es mir im besonderen um das Matching der Toplevel-Domain. Dabei ist vielfach noch hinterlegt, dass diese zwischen zwei und drei Buchstaben lang sein muss. Das gilt aber leider nur bei „country code top level domains“, die eben einem Land gehören. Generische Top Level Domains sind meist länger. Eine“.info“-Domain ist valide, würde aber von obigem Regex nicht gematcht.

strPattern = "^([a-zA-Z0-9_\-\.]+)@[a-z0-9-]+(\.[a-z0-9-]+)*(\.[a-z]{2,})$"

Obiger Regex ist derweil immer noch nur eine Näherung an den IEEE-Standard, filtert aber längere Toplevel-Domains nicht mehr aus.

Leider bietet SQLCL keine Option mit welcher Kodierung die Ausgabe erfolgt. Das lässt sich mit JAVA_TOOL_OPTIONS einstellen. Folgende Befehle in der Kommandozeile (oder einem CMD-Script) bringen SQLCL einmalig dazu, jede Ausgabe ins Filesystem mit UTF8 zu schreiben :

set JAVA_TOOL_OPTIONS='-Dfile.encoding=UTF-8'

Leider ergibt das aber nur UTF8 ohne BOM/Byte Order Mark.
Im Default kann SQLCL oder die CMD nun keine BOM erzeugen. Dabei handelt es sich aber nur um fest kodierte Bytes, die der Datei vorran gestellt werden: EF BB BF

Der Trick in der CMD ist, eine Datei – die nur diese Bytes enthält – dem eigentlichen Export voran zu „stellen“:

 copy utf8bom.txt+export.csv final_export.csv /B 

Die Datei utf8bom.txt steht zum Download bereit. Das Flag „/B“ ist wichtig, bringt es doch den copy-Befehl dazu, die Zeichen binär zu kopieren.

Darüber hinaus gibt es auch eine Variante mit der Powershell, die ich in einem der nächsten Beiträge erörtern möchte.