IoT Hackathon auf der Bosch Connnected Experience 2018

Vom 20. bis zum 22. Februar nahmen Alexis Premet und Philipp Perez an der Bosch ConnectedExperience (BCX) – dem IoT Hackathon auf der Bosch Connected World (BCW) – teil. Hackathon und Konferenz fanden verteilt in mehreren Hallen der STATION Berlin statt. Dabei lag der Schwerpunkt der Konferenz auf dem Thema Internet of Things (IoT).

Während auf der Konferenz Keynotes von bedeutenden Persönlichkeiten, darunter die CEOs von Daimler, Kaspersky, Bosch und der Deutschen Post, stattfanden, trafen sich Developer, Data Scientists und Machine Learning Experts, aber auch UI/UX Experts und Product Manager/-Owner auf dem Hackathon. Mit über 800 Teilnehmern konnte dieses Jahr ein neuer Rekord aufgestellt werden.

Hack Challenges

Der Hackathon ist in folgende, fünf Hack Challenges aufgeteilt:

  • Connected Mobility Services
  • Autonomous Driving
  • Manufacturing 4.0
  • Logistics & Supply Chain 4.0
  • Connected Life

Jede Hack Challenge wurde von einem Hack MC (Master of Ceremonies) geleitet. Ihm stehen rund einem Dutzend Hack Coaches zur Seite, die den Teilnehmern des Hackathons bei allen Belangen helfen.

Weiterlesen

Veröffentlicht unter Analytics & BigData, IoT & Industry 4.0 | Verschlagwortet mit , , , , , , | Kommentar hinterlassen

Azure Functions – Simple JavaScript Tutorial

Bevor wir in das Tutorial einsteigen, sollten wir uns erst einmal anschauen, was Azure Functions überhaupt sind:

Bei Azure Functions handelt es sich um eine Lösung, mit der man kleinere Codefragmente (Funktionen) erstellen und in der Cloud ausführen kann. Bei der Implementierung kann man sich ganz auf das Lösen des jeweiligen Problems konzentrieren und muss sich nicht auch noch um die Infrastruktur kümmern (Serverless Computing). Weiterlesen

Veröffentlicht unter Cloud & Infrastructure | Kommentar hinterlassen

Alexa, wieviel wiege ich? Hackathon: Voice meets IoT in München

Im April haben Christian Ochsenkühn und ich (Tomasz Krajewski) an einem Internet of Things (IoT) Voice Hackathon mit dem Titel Voice meets IoT in München teilgenommen.

1_1

An dem großen Event haben 80 Entwickler aus ganz Deutschland teilgenommen, um Voice Skills für eine Vernetzung zwischen Smart Speakern und Dingen zu entwickeln.

Unsere Idee

Als aktive Menschen finden wir es wichtig Sport zu treiben! Sport ist entscheidend für die Gesundheit und das körperliche Wohlbefinden. Die Zahl der Menschen mit Übergewicht hat sich seit 1975 fast verdreifacht und im Jahre 2016 waren mehr als 1,9 Milliarden Erwachsene übergewichtig. Davon waren über 650 Millionen fettleibig. Mit nur 30 Minuten körperlicher Aktivität an 5 Tagen pro Woche ließen sich die gesundheitlichen Risiken, die durch Übergewicht und Bewegungsmangel entstehen, vermeiden. Daher haben wir uns entschieden einen Skill für den Smart Speaker Alexa zu entwickeln, der den Nutzern helfen soll ihr Körpergewicht zu kontrollieren und sportlich aktiver zu werden. Dazu haben wir eine handelsübliche Badezimmerwaage gehackt und mit einem Controller verbunden. Zusätzlich sollte der Controller die Anzahl an sportlichen Trainingseinheiten zählen. Da der Hackathon nur 24 Stunden umfasste, haben wir nur den ersten Teil unserer Idee umsetzen können.

Unsere Lösung soll den Nutzern helfen ihre Gewichtsdaten digital zu speichern. Mit Hilfe dieser Daten soll Alexa den Nutzer so zum Beispiel Ratschläge geben können, ob man mehr trainieren soll oder nicht. Alexa soll die Nutzer motivieren ihre Trainingseinheiten einzuhalten und nicht aufzugeben, wenn sich nicht sofort Ergebnisse feststellen lassen. Abnehmen und der Aufbau von Muskulatur braucht Zeit und damit ein gutes Durchhaltevermögen. Alexa kann dabei helfen die Motivation aufrechtzuerhalten.

Folgendes Showcase soll unsere Idee grafisch verdeutlichen:

HackathonDiagram(1)

Die folgenden Videos zeigen, wie der Skill funktioniert:

Der Benutzer definiert nur einmal seine Körperdaten. Beim nächsten Mal kennt Alexa alle Grunddaten über den Benutzer und man kann sofort die Waage benutzen und sein Gewicht ermitteln lassen.

Zur Entwicklung des Skills auf dem Hackathon

Die handelsübliche Badezimmerwaage haben wir mit HX-711 Kontroller und Arduino verbunden.

waage

Ein bisschen knifflig war der Aufbau. Wir haben nur die günstigsten Komponenten als auch die günstigste Waage (ca. 5 Euro) auf dem Markt gekauft. Wir hatten keinen Multimeter zur Hand und mussten sehr genau löten. Das war eine Herausforderung am Anfang! Nicht alle unsere Sensoren waren richtig verbunden und wir haben lange Zeit nur falsche Daten empfangen. Wir mussten auch HX-711 Sensor genau kalibrieren. Erst gegen 10 Uhr morgens  haben wir es geschafft, dass alle Komponenten richtig miteinander kommunizierten und mit der Waage korrekt verbunden waren. Diszipliniertes Arbeiten durch die ganze Nacht war notwendig; umso glücklicher waren wir, dass am Ende alles funktioniert hat.

Mit der Entwicklung unseres Skills haben wir den 4. Platz erreicht und waren damit im obersten Viertel. Wir haben sogar eine Kleinigkeit gewonnen, wie ihr im unteren Bild sehen könnt.

1_2

Zwei Kollegen in unserem Team waren Neueinsteiger hinsichtlich Arduino und Alexa Entwicklung. Sie  haben eine steile Lernkurve während des Hackathons absolviert und tatkräftig unterstützt. Leider musste Christian am Samstag früher nach Hause fahren, weil er eine wichtige Familienfeier hatte. Es war aber sehr nett von ihm, dass er uns trotzdem für ein paar Stunden unterstützen wollte. Das zeigt, was für engagierte Mitarbeiter wir bei Opitz Consulting haben!

Leider haben wir am Ende nicht alles Geplante zeigen können, was wir wollten. Die Hürden waren an einigen Stellen doch zu hoch. Dennoch hatten wir sehr viel Spaß in einem tollen Team.

Ich hatte das Glück dieses Mal eine koordinative Rolle miteinnehmen zu dürfen und habe dabei eine Menge gelernt. Einfach war es nicht;-) Ich hatte viel Stress und habe kaum geschlafen. Dennoch war dies für mich eine tolle Erfahrung, da ich so einige meiner Soft und Projektmanagement Skills erproben konnte. Mit dem vierten Platz bin ich mehr als zufrieden.

Als Team haben wir uns vorgenommen, dass wir in der gleichen Konstellation noch einmal auftreten wollen und uns als Team noch weiter verbessern wollen!

Unser Vorgehen und Projekt

Wir haben uns zuerst auf das Backend fokussiert und eine einfache und unabhängige continuous integration (CI) Server Umgebung aufgesetzt. Wenn man in einem Team einen Skill entwickelt, ist dies einfacher als alles erstmal lokal zu entwickeln. So lässt sich alles mit dem alexa-cli und dem CI Server erledigen! Der Ansatz war praktisch, richtig und lieferte für uns schnell Ergebnisse.

Wenn ein Teammitglied seine Änderungen mit Hilfe des SCM Tools git pushed, wird unser Skill sofort deployed und unser Interaktions-Model wird zeitgleich im Developer Portal aktualisiert! Dadurch verliert man keine Zeit etwas händisch im Alexa Portal zu ändern und hat damit eine gute Zeitersparnis erreicht.

Die Umgebung haben wir mit einem Raspberry Pi aufgebaut. Im Folgenden eine kurze Beschreibung, wie wir dies gemacht haben.

Raspberry Pi Configuration

  1. Wir haben einen alten raspberry pi zero benuzt. Zuerst wäre gut alles zu aktualiesieren:
sudo apt-get update
sudo apt-get upgrade
  1. Man muss git-server installieren
sudo apt-get install git-core

Anlegen eines ersten Repositories

mkdir -p /home/pi/project/repository/hack && cd /home/pi/project/repository/hack
  1. Starten des git Repository
git init --bare

 

PC Konfiguration (Pushen)

  1. Öffnen des Repository
git init
  1. Hinzufügen eines remote GiT Repository
git remote add hack pi@192.168.43.47:/home/pi/project/repository/hack
  1. Jetzt können wir Standard GiT Befehle starten
git add .
git commit -m "Our first commit"
git push hack master

PC Konfiguration (Clonen)

  1. Um die Files zu clonen schreiben wir in die Console
git clone pi@192.168.1.108:/home/pi/project/repository/hack

 

Jetzt können wir einen einfachen CI Konzept implementieren:

  1. Gehen wir zu unserem Repository:
cd ~/project/repository/hack/hooks
  1. Erstellen wir ein CI Skript
sudo nano post-receive
  1. Fügen wir hinzu:
#!/bin/bash
TEMP="/home/pi/project/temp"
TARGET="/home/pi/project/deployedSkillHackathon/"
REPO="/home/pi/project/repository/hack/"

while read oldrev newrev ref
do
    if [[ $ref =~ .*/master$ ]];
    then
        echo "Master ref received. Deploying master branch to production..."
                mkdir -p $TEMP
                echo "temp folder created"
                git --work-tree=$TEMP --git-dir=$REPO checkout -f
                echo "checking if I need to install npm modules"
                if cmp $TEMP/package.json $TARGET/package.json; then
                        echo "Ha you havent changed anything in node modules I have less work! "
                else

                        cd $TEMP
                        npm install

                fi
                echo "target folder deleted"
                rm -rf $TARGET
                mv $TEMP $TARGET
    else
        echo "Ref $ref successfully received.  Doing nothing: only the master branch may be deployed on this server."
    fi
done
  1. Rechte hinzufügen
sudo chmod +x post-receive
  1. Wir sind fertig zu deployen!

In einem nächsten Blog Artikel werde ich Skill Eigenschaften genauer beschreiben und ich zeige auf einem neuen Video wie schnell man den Skill mit Raspberry Pi und einfachen CI Server deployen kann.

Veröffentlicht unter Cloud & Infrastructure, IoT & Industry 4.0, News, Software Engineering | Verschlagwortet mit , , , , , | Kommentar hinterlassen

Opitz Consulting became Camunda certified System Integrator

It is over half a year ago that Opitz Consulting became a Camunda certified System Integrator. A lot of time passed since then. In this post, I will share some experiences around the certification as well as the topics of process modeling and architectural decisions.

Camunda Partner Program

The Camunda partner program for system integrators provides three partnership levels: Basic, Certified, and Advanced. Opitz Consulting graduated from level basic to level certified [1]. One might ask for the advantage for our customers and ourselves. I think the subtitle of the certified level on the Camunda website provides the best description: Proven Camunda skills. That’s also why Opitz is a Camunda Certified partner. The knowledge allows us to provide a high quality service to our customers.

camunda-certified-partner-logo

“Proven” means that the partner has at least three certified consultants, developers, or engineers that passed the exam. I also took the exam and have to say that this exam was not the easiest I ever passed. The exam covers the whole Camunda ecosystem. The most important area is of course the BPM platform. Another important area comprises questions about BPMN, CMMN, and DMN. Finally, some questions cover the BPM Life cycle from modeling to monitoring. In other words, it touches every relevant field of a Camunda project. As a candidate, one is forced to deal with the whole range of Camunda’s features, even if they’re not part of your daily project work. This ensures a consistent quality level, if working with any Camunda Certified Engineer.

Lessons Learned

From time to time, I am asked how we support customers to introduce and operate BPM and Camunda. Of course, there is no clear answer to that as we adapt our approach to the client and the project. Nevertheless, there are also subject areas that are at least touched in each project and these will be discussed below.

Based on our long-lasting project experience we can guide our customers through all project phases of a BPM project. Even though we are doing a lot of implementation work, there are also other important fields of work, in which we support our customers. Two of them are especially important when starting a BPM project: architectural decisions and process modeling.

Architectural Decisions

The beauty of Camunda is that it can be used in many architectural setups. It’s possible to integrate the Camunda engine with a lot of architecture styles. We see applications based upon a microservice architecture as well as applications based upon a monolithic architecture. I don’t want to judge on architecture styles in this post but we see sustainable, evolvable architectures basing upon different styles. Even if they are modern, microservices are not the holy grail of architecture. I would propose to decide based on context, constraints, and requirements which style to use.

This flexibility, however, requires careful architecture work. One of the most important decision to be taken is the integration of the engine with the application. For example, one can use a Shared Engine that can be used by a bunch of applications in parallel or one can use an embedded engine configuration that provides the engine for the application exclusively. In my view it’s important to make such decisions explicitly. That helps one to estimate the risks and consequences of the decision. For example, a consequence of using embedded engines for an application is that one doesn’t have a unified task list containing all the tasks from the different applications out of the box. In this case, one has to come up with a custom integration solution that provides the unified task list. In such cases we can provide our customers with a rich set of architecture decision which must be taken. That allows to speed up architecture work and ensures a certain level of quality.

Based on our experience we created a catalog with generic architecture decisions that came up in a lot of projects. From the catalog we have derived a questionnaire that can be used at a new project. The questionnaire helps to speed up the initial project phase and also improves the quality of the decisions.

It is highly recommended to document decisions. This helps to track the decisions over the entire course of a project. At the moment we experiment with Architecture Decision Records (ADR) to further formalize the documentation [2]. Furthermore, we pursue current efforts to place the decisions directly in the source code: The Embedded Architectural Decision Records (E-ADR) [3].

Process Modelling

As soon as I come to a customer, I ask about the processes that we should automate. In most cases if the processes don’t match the level of quality, we need to run the process with Camunda. Most process models I see at customers only reflect the happy path, i.e., they lack in showing alternative paths or error handling. Furthermore, we ask the customers about metrics and SLA, because these are also important topics for process modeling. Hence, we help our customers in a first step to model better processes, by providing guidelines, conventions, patterns, and examples to improve process modeling. My advice is not to underestimate the effort to model business processes, as high quality process models, in my experience, lead to a significantly more reliable execution and more meaningful monitoring.

In most companies, process knowledge is spread over the whole organization. In order to gather the knowledge we help the customer by doing interviews or organizing workshops. The difficulty lies less in the organization than in the different perspectives that different stakeholders have on the process. These different views must be combined to one executable view that covers the engines perspective.

Data flow is also an underestimated dimension of process modeling. We observe that the data flow is at least as complex as the control flow. Furthermore, a lot of complex transformations are necessary, while integrating existing services within a process. Therefore, the data flow should already be considered during the modeling. Otherwise, there is a risk that too many almost identical transformations will occur during the implementation.

We also give our customer the advice not to observe a business process as static. The assumption that a process is modeled once and remains valid for ever simply doesn’t hold. In contrast, the process will evolve. In my current project, we deploy up to three process versions a year. This must also be reflected in the (project) organization. I quite often recognize the pattern where processes are modeled from a business perspective upfront and the people who modeled the processes aren’t available later during the refinement phases. Besides organizational impact, changes of process models also have a technical implication. Long running process instances must be migrated to the new model possibly. Therefore, migration of process instances is an area in which we support our customers.

Finally, we help our customers to implement their own modeling method and convention. A list of basic methods is listed in [4].

Conclusion

Process management is a broad and exciting field of work. Getting started may be a bit complex, but this is exactly where we come in: making process management easy for our customers. I hope by reading this blog post you got an impression what problems we are solving together with our customer and what advantages you have in working with a certified partner: proven knowledge.

References

  1. https://www.opitz-consulting.com/fileadmin/user_upload/Collaterals/Artikel/pm-camunda-bpm-certified-partner.pdf
  2. https://github.com/joelparkerhenderson/architecture_decision_record
  3. https://adr.github.io/e-adr/
  4. https://github.com/ungerts/awesome-bpm
Veröffentlicht unter BPM & System Integration | Verschlagwortet mit , , | Kommentar hinterlassen

Integration in der Cloud – Ein Serverless Ansatz

Integration hat in Zeiten der Digitalisierung nicht an Bedeutung verloren – vielmehr wird diese Disziplin immer wichtiger, um Menschen, Dinge und Maschinen mit den Informationen zu versorgen, die sie benötigen.

Integration muss dabei nicht on-Premise und mit großen, zentralen Integrationsplattformen erfolgen. Cloud und Container haben die Disziplin Integration ebenfalls nachhaltig beeinflusst. Hier sind einige „Platform as a Service“-Produkte entstanden, die eine gute Alternative zu klassischen Integrationsplattformen darstellen.

Weiterlesen

Veröffentlicht unter BPM & System Integration, Cloud & Infrastructure, IoT & Industry 4.0 | Kommentar hinterlassen

AWS News KW 12

Service-Erkennung für ECS

Amazon Elastic Container Service (ECS) bietet ab sofort eine Service-Erkennung. Damit bietet ECS jetzt eine eigene Lösung für ein immer wiederkehrendes Problem mit Docker Containern. Wie kann ich Services aufrufen von denen ich nicht weis wie viele Instanzen es gibt und unter welcher URL sie erreichbar sind? Amazon löst das Problem durch den Einsatz der Route 53 Auto Naming API.

Die Service-Erkennung ist aktuell in folgenden Regionen nutzbar, USA Ost (Nord-Virginia), USA Ost (Ohio), USA West (Oregon) und EU (Irland).

Weitere Informationen zur Service-Erkennung hier.

Längere ID´s für mehr Amazon EC2 Resourcen

Nachdem längere Ressource ID´s für wenige EC2 Ressourcen angekündigt wurden, werden die längeren ID´s jetzt auf alle EC2 Ressourcen ausgerollt. Bis Juli 2018 können die neuen ID´s noch auf Opt-In Basis zum testen verwendet werden. Ab July 2018 werden alle neu angelegten Ressourcen mit den neuen ID´s erzeugt. Bereits bestehende Ressourcen mit den alten ID`s bleiben weiterhin bestehen.

Weitere Informationen zu den Ressource ID´s hier.

Echtzeit Hotspot Erkennung für Amazon Kinesis Analytics

Kinesis Data Analytics ist Amazons fully managed Stream Processing Engine. Es ist möglich mit SQL Querrys in Echtzeit Datenstream zu analysieren. Zu den bereits vorhandenen Analysemöglichkeiten ist jetzt noch die Erkennung von Hotspots in Daten hinzugekommen.

Weitere Informationen zu Kinesis Data Analytics hier.

 

Veröffentlicht unter Cloud & Infrastructure | Kommentar hinterlassen

SOAP and Attachments

Introduction

Service-clients and service-providers are often facing the need for transmitting both binary content and text data in a reliable and efficient way.

This document presents implementation outlines for this scenario. The service-provider has been implemented using the Oracle Service Bus (version 11.1.1.7) while the service-client has been realized using SOAPUI.

W3C Notes and Recommendations.

This document follows the documents SOAP Messages with Attachments: W3C Note 11 December 2000 and the SOAP Message Transmission Optimization Mechanism: W3C Recommendation – 25 January 2005 that describe standards on SOAP Message Transmission.

SOAP-with-Attachments (SwA)

The „SOAP Messages with Attachments: W3C Note 11 December 2000“ states:

„This document defines a binding for a SOAP 1.1 message to be carried within a MIME multipart/related message in such a way that the processing rules for the SOAP 1.1 message are preserved. The MIME multipart mechanism for encapsulation of compound documents can be used to bundle entities related to the SOAP 1.1 message such as attachments. Rules for the usage of URI references to refer to entities bundled within the MIME package are specified.“

 swa

Implementation

Service Provider

We define the xml schema as follows:

<?xml version="1.0" encoding="UTF-8" ?>
<xsd:schema 
  xmlns:xsd="http://www.w3.org/2001/XMLSchema"
  xmlns="http://www.svi.de/SWA" 
  targetNamespace="http://www.svi.de/SWA"
  elementFormDefault="qualified">
  
  <xsd:element name="payload" type="PayloadType" />
  <xsd:complexType name="DocMetaType">
    <xsd:sequence>
      <xsd:element name="Fname" type="xsd:string" />
      <xsd:element name="Fpath" type="xsd:string" />
      <xsd:element name="text" type="xsd:string" />
    </xsd:sequence>
  </xsd:complexType>

  <xsd:complexType name="PayloadType">
    <xsd:sequence>
      <xsd:element name="docInfo" type="DocMetaType" />
    </xsd:sequence>
  </xsd:complexType>


  <xsd:element name="payloadResponse" type="PayloadResponseType" />
  <xsd:complexType name="PayloadResponseType">
    <xsd:sequence>
      <xsd:element name="Fname" type="xsd:string" />
      <xsd:element name="action" type="xsd:string" />
      <xsd:element name="text" type="xsd:string" />
    </xsd:sequence>
  </xsd:complexType>
    
</xsd:schema>

We use a file adapter for saving the attachment. Since the file adapter needs a base64-encoded-string we have to use a Java Callout to encode the byte array from:

$attachments/ctx:attachment/ctx:body/ctx:binary-content

The result string will be passed straight forward to the file adapter.

Service Client

For the Service-Client we use a default request from SOAPUI.

Example:
Request

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:swa="http://www.svi.de/SWA">
   <soapenv:Header/>
   <soapenv:Body>
      <swa:payload>
         <swa:docInfo>
            <swa:Fname>MASTERING_BLOCKCHAIN.pdf</swa:Fname>
            <swa:Fpath>/home/oracle/Downloads/</swa:Fpath>
            <swa:text>some text</swa:text>
         </swa:docInfo>
      </swa:payload>
   </soapenv:Body>
</soapenv:Envelope>

Response:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
   <soapenv:Header xmlns:mtom="http://www.svi.de/SWA"/>
   <soapenv:Body xmlns:mtom="http://www.svi.de/SWA">
      <swa:payloadResponse>
         <swa:Fname>MASTERING_BLOCKCHAIN.pdf</swa:Fname>
         <swa:action>ok</swa:action>
         <swa:text>some text. Message contains 1 attachment</swa:text>
      </swa:payloadResponse>
   </soapenv:Body>
</soapenv:Envelope>

Load Tests

The detailed results:

Various files (pdf, zip, docx, etc.) have been transmitted, with a total of 137 MB. The mean total time was 23 sec., which means an average throughput of 5,9MB/sec.

Attachments over 70 MB were rejected by an Out-Of-Memory Exception.

swa_kpi

SOAP Message Transmission Optimization Mechanism (MTOM)

MTOM optimizes element content that is in the canonical lexical representation of the xsd:base64Binary data type.

Implementation

Service Provider

We define the xml schema as follows:

<?xml version="1.0" encoding="UTF-8" ?>
<xsd:schema 
    xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    xmlns="http://www.svi.de/MTOM" 
    targetNamespace="http://www.svi.de/MTOM"
    elementFormDefault="qualified">
    
    <xsd:element name="payload" type="PayloadType" />
    
    <xsd:complexType name="DocMetaType">
        <xsd:sequence>
            <xsd:element name="Fname" type="xsd:string" />
            <xsd:element name="Fpath" type="xsd:string" />
            <xsd:element name="text" type="xsd:string" />
        </xsd:sequence>
    </xsd:complexType>

    <xsd:complexType name="PayloadType">
        <xsd:sequence>
            <xsd:element name="docInfo" type="DocMetaType" />
            <xsd:element name="document" type="xsd:base64Binary" />
        </xsd:sequence>
    </xsd:complexType>

    <xsd:element name="payloadResponse" type="PayloadResponseType" />
    <xsd:complexType name="PayloadResponseType">
        <xsd:sequence>
            <xsd:element name="Fname" type="xsd:string" />
            <xsd:element name="action" type="xsd:string" />
            <xsd:element name="text" type="xsd:string" />
        </xsd:sequence>
    </xsd:complexType>
    
</xsd:schema>

We use a file adapter for saving the attachment. Since the file adapter needs a base64-encoded-string we have to use a Java Callout to encode the byte array from
$body/mtom:payload/mtom:document/ctx:binary-content

The result will be passed straight forward to the file adapter.

Service Client

In SOAPUI we create a Request and we enable the MTOM parameter

mtom-enable

Example:

Request

<soapenv:Envelope
  xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
  xmlns:mtom="http://www.svi.de/MTOM">
   <soapenv:Header/>
   <soapenv:Body>
      <mtom:payload>
         <mtom:docInfo>
            <mtom:Fname>MASTERING_BLOCKCHAIN.pdf</mtom:Fname>
            <mtom:Fpath>/home/oracle/Downloads/</mtom:Fpath>
            <mtom:text>some Text</mtom:text>
         </mtom:docInfo>
         <mtom:document>cid:9781787125445-MASTERING_BLOCKCHAIN.pdf</mtom:document>
      </mtom:payload>
   </soapenv:Body>
</soapenv:Envelope>

Response:

<soapenv:Envelope 
  xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
   <soapenv:Header xmlns:mtom="http://www.svi.de/MTOM"/>
   <soapenv:Body xmlns:mtom="http://www.svi.de/MTOM">
      <mtom:payloadResponse>
         <mtom:Fname>MASTERING_BLOCKCHAIN.pdf</mtom:Fname>
         <mtom:action>ok</mtom:action>
         <mtom:text>some Text</mtom:text>
      </mtom:payloadResponse>
   </soapenv:Body>
</soapenv:Envelope>

Load-Tests

The detailed results:

Various files (pdf, zip, docx, etc.) have been transmitted, with a total of 137 MB. The mean total time was 15 sec., which means an average throughput of 9.1 MB/sec.
Attachments over 70 MB were rejected by an out-of-Memory Exception.

mtom_kpi

Simple base64 Java Encoder

The following code for the java base64-encoder can be used by the Java Callout

package de.svi.att.tools;
import weblogic.utils.encoders.BASE64Encoder;
public class SVIBase64Encoder{
  public static String encode(byte[] bytes){
    BASE64Encoder encoder = new BASE64Encoder();
    String encodedString = encoder.encodeBuffer(bytes);
    return encodedString;
  }
}

Conclusion

We have implemented a client using SOAPUI and a service provider using OSB and a VM with the oracle SOA Suite Appliance 11.1.1.7 in order to compare the methods SwA and MTOM.

The MTOM mechanism has a performance advantage of 15%-30% compared to the SwA method.

None of the load tests led to a drop of server-performance due to garbage collection actions.

No Problems when dealing with special characters have been observed.

Veröffentlicht unter BPM & System Integration | Verschlagwortet mit , | Kommentar hinterlassen