Tools und Tipps vom Developercamp 2017

Nach dem Camp ist auf dem Camp – erst das Devops Camp letztes Wochenende, nun das Developer Camp im Rahmen der Webweek Nürnberg.

Auch auf dem DevCamp gibt es natürlich zahlreiche interessante Sessions mit vielen Tools und Tipps für den Entwickler-Alltag. Hier eine selektive Auswahl aus Sessions, die ich bisher besucht habe – viel Spass! 🙂

Webassembly

React Native

Big Data

Ramda.js / Functional programming

NPM

Monolith zu Microservice

REST-Backend

Ansible

Documentation

Deep Learning

Sonstiges

DevOps Camp 2017 Tool-Tipps

Das DevOps Camp 2017 vom 12.-14. Mai 2017 bot wieder zahlreiche interessante Vorträge, Diskussionen und Leute, tolles Essen und super Atmosphäre. Ein komplettes Recap folgt später, hier schonmal eine kleine Link-Sammlung für Tipps und Tools, die ich beim DevOps-Camp (wieder-)entdeckt habe bzw. die ich mir nun endlich einmal ansehen muss 🙂

Hier werde ich sicher noch einige ergänzen, schaut gelegentlich mal vorbei 🙂

 

 

OXID Artikel-Importer

Bei OXID Exchange finden Sie den rent-a-hero Artikelimporter für OXID eShops der Version 4.x / 5.x (CE, PE und EE).
Dabei handelt es sich um ein Modul zum Importieren / Aktualisieren von Artikeln, Bildern und damit zusammenhängenden Daten (Artikeltexte, SEO Daten, Attribute, Auswahllisten, Crossselling, usw.) mittels CSV-Dateien.

Neben den Feldern der Tabelle oxarticles können auch andere Tabellen befüllt werden. Aktuell können Langtext (oxartextends), SEO-Keywords und Description (oxseo), Attribute (oxattribute, oxobject2attribute), Auswahllisten (oxselectlist, oxobject2selectlist), Hersteller und Lieferanten (oxvendor und oxmanufacturers) automatisch angelegt und zugeordnet werden. Es werden auch Auswahllisten neu angelegt, falls noch nicht vorhanden.
Weiterhin ist es möglich, die Artikel in eine beliebige Kategorie zu importieren. Ausserdem können aus Bildern, die per FTP  hochgeladen werden automatisch alle relevanten Shop-Bilder generiert werden. Das Modul kann damit auch zum Skalieren der Shopbilder eingesetzt werden.
Generell kann der Import beliebig oft wiederholt werden, die bereits vorhandenen Daten werden dann überschrieben/aktualisiert. Der Import kann auch per Cronjob automatisiert werden.

NEU in Version 2.3.0.: es können nun auch externe Bilder per URLs heruntergeladen und importiert werden! Verfügbar bis OXID 4.10 bzw. 5.3.!

Der Preis beträgt 199 EUR (plus MwSt.) für die CE-Version und 249 EUR (plus MwSt.) für die kostenpflichtigen PE/EE Versionen. Sie können auch direkt bei uns per Rechnung bestellen, kontaktieren Sie uns einfach!

OXID|Json – REST Schnittstelle für den OXID eShop mit AngularJS Frontend auf Github

Seit einigen Wochen auf Github verfügbar: OXID|Json!

OXID|Json bietet ein CRUD-Interface (Create, Read, Update, Delete)
für den OXID eShop an und enthält ein mit AngularJS erstelltes
Frontend, mit dem die wichtigsten Funktionen getestet werden können.

Das Frontend erlaubt die “Inline”-Bearbeitung aller Daten, die Daten
können sortiert, gefiltert und modifiziert werden. Durch die Verwendung
des Responsive-Frameworks “Twitter Bootstrap” ist die Oberfläche auch mit mobilen Endgeräten nutzbar.

Die REST-Schnittstelle basiert auf Tonic und ist nach einem verschlüsselten Login mit Shop-Zugangsdaten je nach Rechten read-only oder mit Vollzugriff nutzbar.

Define associative arrays in Smarty

Here is a quick and dirty way to define an associative array in Smarty 🙂

[{ assign var='myArray' value='/[\s,:]+/'|preg_split:"Blue:blue.png,Black:black.png,Red:deep_red.png"}]
[{section loop=$myArray name=item step=2}]
[{assign var="midx" value=$smarty.section.item.index+1}]
Key: [{$myArray[item]}] - Value: [{ $myArray[$midx] }]<br>
[{/section }]

PHP Tipps – Arbeiten mit SAP IDoc Dateien

SAP IDoc (Intermediate Document) wird von SAP intern verwendet, um z.B. Bestelldaten abzubilden. In der Regel werden IDoc-Daten mittels Message Mapping in andere Formate hin- und herkonvertiert, z.B. in EDIFACT.
Eine generelle Definition von IDoc findet sich z.B. auf www.php-deluxe.de:

Ein IDoc besteht nur aus Textzeichen und besteht aus einem Kontrollsatz, den Datensätzen und Statussätzen.

Der Kontrollsatz besteht aus Sender, Empfänger, Nachrichtentyp und
IDoc-Typ. Der IDoc-Typ beschreibt die Struktur der Datensätze, der
Nachrichtentyp entspricht einem in dem IDoc-Typ definierten, konkreten
Geschäftsvorfall (z.B. Bestellung, Lieferung).

In den Datensätzen sind die zu übertragenden Informationen enthalten, der Aufbau entspricht grundsätzlich einer Datenbanktabelle mit einer durch den IDoc-Typ definierten Struktur und den dazugehörigen Datensegmenten.

In den Statussätzen sind im IDoc-Format Verwaltungsinformationen wie
Bearbeitungsbeginn, Übermittlungszeit, Fehlermeldungen und ähnliches
abgelegt.

Prinzipiell können IDocs auch im XML-Format verwendet werden, dennoch ist das „klassische“ IDoc Format immer noch weit verbreitet, nicht zuletzt wegen des geringeren Datenvolumens durch die „schlankere“ Struktur.
Dieses „klassische“ IDoc-Format ist gekennzeichnet durch „feste Satzlängen“, d.h. eine Zeile im IDoc ist genau spezifiziert, was die Position der Datensätze (Offsets) und die „Zeilenlänge“ angeht. So kann z.B. eine Zeile im Dokument (Beispiel aus der „ORDERS05“ Struktur) folgendermaßen definiert sein:

Segment E1EDK01:

Segmentdefinition E2EDK01005
freigegeben seit Release 45B , Segmentlänge : 0357

  1. ACTION : Aktionscode, der die gesamte
    EDI-Nachricht betrifft.
    interner Datentyp : CHAR
    interne Länge : 000003 Stellen
    Position in Segment : 001, Offset : 0063. externe Länge : 000003
  2. KZABS : Kennzeichen für
    Auftragsbestätigungspflicht
    interner Datentyp : CHAR
    interne Länge : 000001 Stellen
    Position in Segment : 002, Offset : 0066. externe Länge : 000001
  3. CURCY : Währunginterner Datentyp : CHAR
    interne Länge : 000003 Stellen
    Position in Segment : 003, Offset : 0067. externe Länge : 000003
  4. usw.

Der Parameter „ACTION“ ist also vom Typ „CHAR“, steht in der Zeile, die mit „E1EDK01“ beginnt, an Offset 63 und hat eine Länge von 3 Zeichen, danach kommt der Parameter „KZABS“, dieser steht an Stelle/Offset 66, ist ebenfalls ein „CHAR“ und hat eine Länge von einem Zeichen usw.

Dies würde nun folgendermaßen aussehen:

E1EDK01005                       ABC                           1

wobei sich rechts ggf. noch weitere Werte anschliessen würden.

Zudem hat jede „Zeile“ im Normalfall eine feste Zeichenlänge, unser Beispiel-Segment muss insgesamt 1063 Zeichen haben – stehen am Ende keine Werte, muss die Zeile mit Leerzeichen „aufgefüllt“ werden.

Für einen „IDoc Writer“ in PHP bräuchte man also vor allem eine Möglichkeit, Zeichenketten von vorgegebener (maximaler) Länge an bestimmte Stellen (Offsets) einer Zeile zu schreiben sowie die Zeile mit Leerzeichen bis zum Ende aufzufüllen. Ist eine Zeichenkette / ein Wert länger als an dem vorgegebenen Offset „Platz“ ist, muss die Zeichenkette gegebenenfalls abgeschnitten werden, um nicht versehentlich den Wert am nächsten Offset zu überschreiben. Zeilen werden im Regelfall nur mit „Line Feed“ beendet (in PHP entspricht dies „\n“):

 

$idocWriter =  new smxIdocWriter();
$idocWriter->write(array("E1EDKA1","AG", "0815", "Stefan Moises", "Some company", "Street 45a"), array(0,63,66,100,135,240), 1063);
$idocWriter->toFile("/tmp/test_idoc.dat");

 

Ein kleiner Tipp am Rande: werden die IDoc-Dateien nach Erstellung per FTP transportiert, sollten diese im Binär-Modus versendet werden, da FTP im ASCII-Modus die Eigenart hat, am Zeilenende zusätzlich zum „Line Feed“ auch ein „Carriage Return“ (in PHP „\r“) einzufügen – zumindest macht dies der „ftp_put()“ Befehl in PHP, wenn man ihm FTP_ASCII statt FTP_BINARY als Transfer-Typ übergibt).

Viel Spass mit IDoc! 🙂 Hier gibt es eine einfache IDoc-Klasse zum Download: smxIdocWriter.php_.txt.

PHP Tipps: Verborgene Talente – Teil 2

Immer wieder einmal kommt man als Entwickler in die Situation, lange Texte auf mehrere Zeilen aufteilen zu müssen, die eine maximale Länge nicht überschreiten dürfen – ein typisches Beispiel ist z.B. ein mehrzeiliger Kommentar-Text in einem PDF-Dokument, das man mittels einer PHP-Bibliothek wie FPDF erzeugen möchte. Wie teile ich diesen Text auf mehrere Zeilen auf, ohne Wörter mittendrin abzuschneiden?

Nun, in PHP ist das sehr einfach, man muss den Text nicht mühsam mit Regular Expressions oder gar substr() zerlegen, sondern kann dazu die Funktion wordwrap() nutzen:

$mText = wordwrap  ( $orderInfoText, 70, "---", false );
$mTextArray = split("---", $mText);
foreach($mTextArray as $textLine)
{
echo $textLine . "<br />";

}

Dieser Codeschnippsel erzeugt ein Array von Texten mit jeweils maximal 70 Zeichen Länge, die man dann z.B. in einer Schleife ausgeben kann. Der letzte Parameter in der Funktion, hier mit dem Wert „false“, gibt an, ob Wörter „zerschnitten“ werden sollen – was in den meisten Fällen aber nicht gewünscht sein dürfte.
Der vorletzte Parameter fügt am Ende jeder „Zeile“ den String „—“ ein (man kann natürlich jeden anderen beliebigen String verwenden, nur sollte dieser nicht im Text selbst vorkommen), anhand dessen dann der Text in ein Array gesplittet werden kann – hier könnte man natürlich auch gleich „<br />“ oder „\n“ verwenden, um den Text auf mehrere Zeilen zu „verteilen“. Für eine Verarbeitung z.B. mit FPDF ist allerdings ein Array mit einzelnen „Zeilen“ wesentlich praktischer, diese können dann in einer Schleife dem PDF-Dokument hinzugefügt werden.