Microsoft Azure IoT – Ein Überblick

Internet der Dinge, Industrie 4.0 und- Digitalisierung begegnen uns als Begriffe mittlerweile beinahe täglich. Daher ist es nicht verwunderlich, dass diese Themen auch Einzug im Bereich Cloud gehalten haben. Mittlerweile gibt es eine Vielzahl an Herstellern, die mittels einer Cloud verschiedene IoT relevante Funktionen anbieten, wie zum Beispiel die Azure IoT Suite von Microsoft.

Im Rahmen dieses Artikels wird eine Übersicht über die Funktionen der Microsoft Azure IoT Cloud Lösung gegeben und deren Funktionen dargestellt.

Möchte man Azure speziell für das Internet der Dinge nutzen, steht ein Set an Features über die Azure IoT Suite zu Verfügung. Die IoT Suite bietet alle nötigen Dienste für das Internet der Dinge an. Für den schnellen Start in die IoT Welt von Azure steht in der IoT Suite vollständig konfigurierte Lösung zur Remoteüberwachung und zur vorbeugenden Wartung von Maschinen bereit. Auf die Cloud aufbauende Lösungen können individuell an eigene Anforderungen angepasst und konfiguriert werden.

In einer Vorkonfigurierte Lösung ist eine hohe Anzahl an Diensten gebucht die in einem Nutzungsbasierten Account nach Ressourcenverbrauch abgerechnet werden. Die in der IoT Suite gebuchten Dienste werden nach Zeit, Größe von Messages, Anzahl der Messages und nach dem Standort abgerechnet. Für die vorkonfigurierten Lösungen sind mehrere simulierte Geräte implementiert die einen hohen Ressourcenverbrauch generieren und damit hohe Kosten verursachen. Beim Testen der IoT Suite darauf achten das nicht benötigte Dienste und Geräte deaktiviert werden. Man erhält zum Testen 170€ Guthaben, diese sind aber je nach Testfall und Dienst in ein paar Tagen ausgeschöpft.

Die unten stehende Abbildung beschreibt die IoT Lösung im Microsoft Azure Umfeld, auf die im Folgenden weiter Bezug genommen wird. Im Device connectivity werden die erzeugten Daten der IoT-Geräte erfasst und dem IoT-Solution-Backend zu Verfügung gestellt. Im Data processing and analytics werden die Daten verarbeitet und übermittelt an die Business-Anwendung zur Integration in bestehende Geschäftsprozesse oder in ein Dashboard zur Visualisierung und Interaktion mit einem Benutzer.


Microsoft Azure IoT Reference Architecture
Quelle: https://azure.microsoft.com/de-de/updates/microsoft-azure-iot-reference-architecture-available/

IoT Geräte werden im Device connectivity mit dem Cloud Gateway verbunden. Die IoT Geräte haben andere Client Eigenschaften als mobile Apps oder Browser. IoT Geräte können Sensoren sein die physisch sehr schwer zu erreichbar sind und ohne menschliches Eingreifen Daten erzeugen. Die Leistungsfähigkeit, Stromversorgung, Netzwerkverbindung sowie branchenspezifische Protokolle machen das Bedienen der Geräte mit herkömmlichen Technologien sehr kompliziert und kostspielig. Die Microsoft Azure IoT Lösung bietet eine sichere, bidirektionale Kommunikation zwischen Geräten und Back-End an. Die Lösung umfasst spezielle Dienste und IoT-Geräte-SDKs um eine Implementierung spezieller Fachanforderungen so einfach wie möglich zu gestallten. Mit .NET-, Java-, Node-, Python-, Ruby- und PHP- SDK biete Azure eine große Auswahl um an Cloud-Ressourcen und Dienste zugreifen zu können.

Der Cloud Gateway bietet Funktionen zur Verwaltung, Registrierung, Steuerung der Kommunikation und zur Überwachung des Status der Geräte. Die Kommunikation findet mit AMQP, MQTT und HTTP direkt mit einem Endpunkt eines Cloud Gateway‘s statt. Die Geräte mit branchenspezifischen Protokollen können durch einen IoT Hub- Protokollgateway in eines der unterstützenden Protokolle übersetz werden. Der Cloud Gateway entscheidet was mit den von IoT Geräten erzeugten Daten geschehen soll und leitet die Daten dementsprechend an einen zuständigen Dienst weiter. Aus der Cloud heraus können auch Befehle an ein bestimmtes Gerät gesendet werden.

Die Datenverarbeitung erfolgt in dem IoT Solution Back End. Das Solution Back End filtert und aggregiert die Telemetriedaten. Die Daten werden an einen Dienst weitergeleitet der aufgrund aktueller Begebenheiten einen Befehl an einen Gerät aussendet oder Daten in einem Dashboard visualisiert.

Die Präsentation und Business Connectivity ermöglicht einem End-Benutzer die Daten visuell bereitzustellen und bietet Interaktionsmöglichkeiten mit den Geräten an. Der Benutzer kann mit einem Dashboard mit dem verbundenen Gerät interaktiv kommunizieren und die erzeugten Werte in Echtzeit einsehen. Die Business Connectivity ermöglicht die Integration der IoT Lösung in die bestehenden Geschäftsprozesse um automatisiert auf Ereignisse anhand der erzeugten Telemetriedaten reagieren zu können.

Die IoT Lösungen können mit den angebotenen Diensten in der Azure Cloud erstellt und verwaltet werden dazu wird eines der von Microsoft angebotenen Accounts benötigt. Microsoft bietet fünf Variationen an, um einen Account zu erstellen:

  • Nutzungsbasierter Account
    -wird mit standardmäßigen Sätzen nach Nutzung abgerechnet
  • Kostenloser Default Account
    – 170€ Startguthaben zum Testen der Dienste
    – kann jederzeit in ein Nutzungsbasierten- Account umgewandelt
  • Abonnement Account
    – Vorauszahlung für 12 Monate
    – 5% Rabatt auf die gebuchten Azure Dienste
    – Mindestbetrag beträgt 5060€
    – Nach 12 Monaten verfällt das nicht verbrauchte Guthaben
  • Microsoft Reseller Volumenlizenzen
    – Open Lizenz Programm welches über Vertragshändler erworben wird
  • Enterprise Agreements
    – Individuelle Verträge für Großunternehmen

Die Verwaltung des angelegten Accounts erfolgt auf account.windowsazure.com. In diesem Verwaltungsportal können laufende Kosten und Nutzungsdetails der Dienste eingesehen werden. Des Weiteren kann das Profil und die Zahlungsart bearbeitet werden.

Das Portal auf portal.azure.com bietet eine Übersicht der gebuchten und zu buchenden Dienste an. Hier können einzelne Dienste konfiguriert und eingesehen werden. Es können auch Kosten und Ressourcenverbrauch der einzelnen Dienste nachverfolgt werden. Des Weiteren bietet das Portal Benutzerverwaltung an, in der man Benutzer anlegen und dem Benutzer Rechte vergeben kann.

Veröffentlicht unter cloud, Cloud Computing, German, IoT | Kommentar hinterlassen

SOA Suite 12.2.1.1.0: Create, configure and tune a SOA/OSB Domain

Introduction

This post focuses on the creation, configuration and tuning of an initial SOA Suite 12.2.1.1.0 Domain.

The WebLogic Server is a necessary requirement, and must already be installed. For instruction how to install the WebLogic Server 12.2.1.1 please refer to my previous post:  WebLogic Server 12.2.1.1.0: Installation on the Linux OS

The following tasks will be implemented:

  • Preparing the Operating System for the installation of the WebLogic Server 12.2.1.1, Installation JDK 1.8 and the WebLogic Server 12.2.1.1: WebLogic Server 12.2.1.1.0: Installation on the Linux OS
  • Creating of database schemas
  • Creating a SOA Suite Domain
  • Post-Installation Tasks:
    • Configuring of components
    • Creating of Start & Stop scripts for the automatic start/stop of components
  • SOA Suite Domain Tuning and Troubleshooting

The SOA/OSB Domain will be installed without BAM (different Domain) because of:

–    Oracle Best Practices and our experience

–    In order to stabilize the system (BAM is unstable at the moment)

The Domain will be created on two servers (OS OEL 6.7):

  • host01.example.com
  • host02.example.com

We will configure four clusters:

  • OWSM Cluster (Oracle Web Services Management)
  • ESS Cluster (Enterprise Scheduler Services)
  • SOA Cluster
  • OSB Cluster (Oracle Service Bus)

Installation SOA / OSB 12.2.1.1

Note: All tasks described in this chapter must be running on both servers: host01 and host02

Weiterlesen

Veröffentlicht unter Configuration, Installation, Oracle FMW, Oracle Service Bus, Oracle SOA Suite, SOA, Uncategorized, Weblogic Server | Verschlagwortet mit , , , , , , , , , , , , , , , | Kommentar hinterlassen

WebLogic Server 12.2.1.1.0: Create, configure and tune a Domain

change_on_install ... an oracle blog

Introduction

This post focuses on the creation, configuration and tuning of an initial WebLogic Server 12.2.1.1.0 Domain.

The WebLogic Server is a necessary requirement, and must already be installed. For instruction how to install the WebLogic Server 12.2.1.1 please refer to my previous post: WebLogic Server 12.2.1.1.0: Installation on the Linux OS

The following tasks will be implemented:

  • Preparing the Operating System for the installation of the WebLogic Server 12.2.1.1, Installation JDK 1.8 and the WebLogic Server 12.2.1.1: please refer to WebLogic Server 12.2.1.1.0: Installation on the Linux OS
  • Creating of database schemas
  • Creating an initial WebLogic Domain
  • Post-Installation Tasks:
    • Configuring of components
    • Creating of Start & Stop scripts for the automatic start/stop of components
  • WebLogic Domain Tuning and Troubleshooting

The Domain will be reated on two servers (OS OEL 6.7):

  • host01.example.com
  • host02.example.com

We will configure two managed Server for Web Services in cluster:

Ursprünglichen Post anzeigen 2.278 weitere Wörter

Veröffentlicht unter Configuration, Installation, Oracle FMW, Weblogic Server | Verschlagwortet mit , , , , , , , | Kommentar hinterlassen

How to customize Java Virtual Machine Settings in Oracle WebLogic Server 12 on OS Linux / UNIX

change_on_install ... an oracle blog

In order to achieve the best performance of the application or to avoid performance bottlenecks (and “OutOfMemory” problems) you need to tune your Java Virtual Machine. After you install the WebLogic Server and create a Domain (WebLogic or SOA or Forms or OBIEE etc.) you may set some properties such as Java “Heap size”, tune Java “Garbage Collection” and WebLogic Server start options.

Tune JVM settings

You can set the Variable USER_MEM_ARGS for the Admin Server and each Managed Server to tune the JVM Parameters. For Example:

USER_MEM_ARGS="-Xms1g -Xmx3g -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:NewSize=1g"

Ursprünglichen Post anzeigen 532 weitere Wörter

Veröffentlicht unter Oracle FMW, Oracle SOA Suite, SOA, Weblogic Server | Verschlagwortet mit , , , , , , | Kommentar hinterlassen

Servicebus 12c: Using configuration files for customizing service deployments

Introduction

In my last projects I faced different challenges in the area of how to manage environment-specific artefact configurations that need to be adjusted during rollout of a particular service component. As a result from that, I decided to write down my experiences and solution approaches regarding the corresponding topics. This article is the starting point for a short blog series dealing with different challenges in this area, where the following topics will be covered:

  • General: Using configuration files for customizing service deployments
  • Adjust environment-specific configurations at deployment time
  • Evaluating environment-specific configurations at runtime
  • Security: Approaches for credentials management

Configuration files in Servicebus

During its lifecycle a specific service component needs to pass different quality gates to ensure quality, correctness and stability before it will be approved for production rollout. For that reason deployments to different environments have to be done. This usually means changes in configurations like service endpoints or timeout parameters, which must be possible without changing a components implementation and rebuilding the component. In Oracle Servicebus this can be achieved by using so called configuration files (aka customization files in OSB 11g). With those it is possible to consistently change service properties and configurations for implementation artefacts like proxy services, service pipelines and business services. Within a configuration file you define actions like replace or search and replace to adjust the corresponding configurations.

Generating a basic configuration file can be done using Servicebus console.

Create_Customization_File

As it can be seen in the screenshot above the services that should be adjusted by the configuration file can be selected. Doing so, a file is generated containing replace rules for all configurations that are adjustable.

One thing to notice, when working with Servicebus configuration files is that actions, which are used to replace parameters may throw errors at deployment time, if services are referenced explicitly by name and the referenced services are:

  • not part of the current deployment,
  • already deployed on the server yet.

Approaches for using configuration files

Depending on the requirements, it can be chosen between a local and a global approach while working with configuration files. The main differences regarding these approaches is the level of granularity in which adjustments are possible, the way the configuration file is defined and the way how configuration files are organized.

Central configuration management using property files

A common detail for both approaches: The configuration file is used in a template style, where specific configurations are expressed as properties, like hostnames or ports.The values for the properties are defined in environment-specific property files. At deployment time, the property file for the target environment is used for replacing the corresponding properties in the configuration file template. This can for example be done by using the maven replacer plugin. Using that approach ensures that only one configuration file needs to be maintained, instead of one per environment.

A property file may look like the following:

sbserver.clusteraddress=sbcluster.test
helloworld.retryCount=0

Local configuration file approach

A local approach demands an explicit configuration file per Servicebus project. So in case a new service is implemented, a new configuration file needs to be created, which should be explicitly used for this service. In addition the central property files have to be adjusted to contain the newly created properties.

Because every project has its own configuration file, the approach is very powerful regarding the granularity of how configuration parameter replacements can be defined, as the replacements are clearly related to a specific service. One difficulty of this approach is that an explicit configuration file needs to be maintained per service, which can become a bit messy.

In the following an example for a fine grained, service-specific action is shown:

<cus:customization xsi:type="cus:EnvValueActionsCustomizationType">
 <cus:description/>
 <cus:owners>
 <xt:owner>
 <xt:type>BusinessService</xt:type>
 <xt:path>service/v1/HelloWorldService</xt:path>
 </xt:owner>
 </cus:owners>
<cus:actions>
<xt:replace>
 <xt:envValueType>Service URI</xt:envValueType>
 <xt:location>0</xt:location>
 <xt:value xsi:type="xs:string" xmlns:xs="http://www.w3.org/2001/XMLSchema">
 http://${sbserver.clusteraddress}/HelloWorldSvc
 </xt:value>
</xt:replace>
<xt:replace>
 <xt:envValueType>Service URI Table</xt:envValueType>
 <xt:value xsi:type="tran:URITableType" xmlns:tran="http://www.bea.com/wli/sb/transports">
 <tran:tableElement>
 <tran:URI>http://${sbserver.clusteraddress}/HelloWorldSvc</tran:URI>
 <tran:weight>0</tran:weight>
 </tran:tableElement>
 </xt:value>
</xt:replace>
<xt:replace>
 <xt:envValueType>Service Retry Count</xt:envValueType>
 <xt:value xsi:type="xs:string" xmlns:xs="http://www.w3.org/2001/XMLSchema">
 ${helloworld.retryCount}
 </xt:value>
 </xt:replace>
</cus:actions>
</cus:customization>

Global configuration file approach

Using a global approach, only one central configuration fileis needed, which defines the replacements for all services. So if a new service is created, only the central configuration file and the property files need to be adjusted, to replace the respective configurations of the new service.

As the configuration file is global and used every time a service is deployed, there are limitations regarding the actions to be used and so also regarding the configuration parameters that can be replaced. It works without any problems, when all actions used do not reference a service by name explicitly. The actions should only specify the type of service, which should be touched (proxy or business service). So those replacement rules are generic and very flexible.

Usually configuration files defined in this style are clear and comprehensible, but limited regarding the granularity of the replacements. It is perfectly fine and easy to manipulate service endpoints (hostname, ports, URLs), but properties like HTTP connection timeout or other numeric configuration parameters are hard to replace using global configuration files, because usually those configurations are specific to a explicit service.

An example for a generic action is a search and replace, which may look like the following:

<cus:customization xsi:type="cus:FindAndReplaceCustomizationType">       
  <cus:description/>
  <cus:query>
    <xt:resourceTypes>BusinessService</xt:resourceTypes>
    <xt:includeOnlyModifiedResources>true</xt:includeOnlyModifiedResources>
    <xt:searchString>http://devserver.com:7101</xt:searchString>
    <xt:isCompleteMatch>false</xt:isCompleteMatch>
  </cus:query>
  <cus:replacement>https://${sbserver.clusteraddress}</cus:replacement>
</cus:customization>

Conclusion

The decision, if the local or the global approach is more applicable, should be clarified depending on the requirements in a particular project. In most of the projects, in which I was involved, the global approach described in this article was adequate. Usually it is sufficient to just replace information regarding the service endpoints. But if more control regarding replacements is needed, the local approach is definitely the one to prefer.

In the next article of this series, it will be shown, how to deal with configurations, which cannot be directly manipulated with the configuration files. An example for that is that depending on the current environment a different API key is needed in the header of the HTTP request.

Veröffentlicht unter Oracle FMW, Oracle Service Bus, Oracle SOA Suite, SOA | Verschlagwortet mit , , , , , | 2 Kommentare

Camunda – Jetzt auch eine Zero-code BPM Lösung?

Camunda wirbt ja schon sehr lange damit, dass Ihre Lösung die richtigen Dinge umsetzt und die Vorteile von Individualentwicklung mit denen sog. BPM-Suites verbindet. BPM-Suites versprechen sehr häufig eine Automatisierung der Geschäftsprozesse ohne IT Unterstützung, also zero-code BPM oder wie camunda auch sagt „Bullshit BPM“.

In der Praxis kennt man das ja, der Fachabteilung ist die IT häufig noch ein Rätsel. Umsetzung neuer Funktionen erscheinen schwierig und benötigen viel Zeit. Doch der Fachbereich möchte die Umsetzung der Anforderungen immer zügiger und der Wunsch nach Selbstbestimmung wird laut. Es wird vom Fachbereich also nach Lösungen gesucht, BPM als Synonym für BPM-Suites und damit zero-code scheinen die richtige Wahl zu sein.

Anbieter werden eingeladen und evaluiert, auf den ersten Blick sieht es nach der ultimativen Lösung aus. Leider scheitern viele dieser Ansätze. Die Lösungen können die Erwartungshaltungen häufig nicht erfüllen und man stößt an vielen Stellen an die Grenzen der Möglichkeiten. Die teure Suite scheint sich also nicht bezahlt zu machen.

Camunda hat bisher einen anderen Ansatz vertreten und sich eben auf die Ausführungsebene (die Process Engine) konzentriert. Zur Umsetzung von Geschäftsprozessen wird die IT also weiterhin benötigt, die für die Fachabteilung eigentlich wichtigen Punkte werden dabei adressiert. Transparenz (ein gemeinsames BPMN Modell) und Umsetzungsgeschwindigkeit (die Engine bringt schon vieles mit und entlastet den Entwickler).

So weit so gut, doch was ist jetzt mit camunda los? Wird camunda auch zu einer zero-code BPM Lösung?

Seit der neuen Version 7.5, die am 31.05.2016 veröffentlicht wurde, ist nun ein neues Feature enthalten. Die sog. „Element Templates“.

Die Element Templates ermöglichen es, durch Vorfertigung von parametrisierten Java-Klassen und einer XML-Beschreibung, dass auch Nicht-Entwickler bzw. fachbereichsnahe Entwickler (citizen developers) durch Konfiguration über den camunda Modeller viele Dinge selbst erledigen können. Eine hohe Wiederverwendung der so erstellten Java-Klassen wird dadurch außerdem gewährleistet.

Ein gutes Anwendungsszenario dürften wohl Emails sein, die aus Prozessen heraus versendet werden sollen. Für dieses Beispiel möchte ich auf den camunda Blog verlinken: https://blog.camunda.org/post/2016/05/camunda-modeler-element-templates/

Weitere Anwendungsszenarien könnten sein:

  • Templates für System-Connectoren (z.B. ERP, CMS, DMS..)
  • Customizing von Workflows/Prozessen (z.B. für Mandanten)
  • Bereitstellung einer anpassbaren Standardsoftware
  • Uvm.

Element Templates können auf viele BPMN Typen angewandt werden, darunter aktuell „Activities“, „Sequence Flow“ (conditions) und „Process“. Durch die breite Basis, freue ich mich schon auf die vielen Einsätze in der Praxis.

Mit dem neuen Feature hält camunda also eine sinnvolle Ergänzung bereit und bleibt seiner Linie, die richtigen Dinge zu tun, auch weiterhin treu.
Für mich persönlich ist dieses Feature eines der Wichtigsten aus dem neuen Release 7.5.

 

Veröffentlicht unter BPM, camunda BPM, German | 1 Kommentar

Migrating Business Processes using Camundas Version Migration Plugin

In a recent project, I was faced with several versions of a process model and a lot of instances for each version. This increased the work of keeping every case in mind for example when it came to new backend developments (which are centralized and have to work for all versions). I had the idea of simply migrating all older instances to the latest version to keep life simple.
I checked out Camundas Version Migration Plugin for Cockpit because I was hoping to get some order in the mess. Here is what I did.

First of all, I installed the plugin. For that, I cloned the project and simply built the jar using mvn install. After that I found the jar in the target folder.
I put that jar into the lib folder of camunda on my tomcat (../apache-tomcat-7.0.62/webapps/camunda/WEB-INF/lib/) and started the server. The cockpit plugin appears as a newly added tab in instance view, see picture below.

8

 

If you havent had a strange feeling about version migration in your stomache already, you will have it now, reading „you are playing with fire!“. I strongly recommend reading the linked Risks and Limitations section, you can find on git.

Brave as I am, I started playing with fire.

My first step was to deploy a simple one-usertask-process and to start several instances for migration:
1.png

Done that, I slightly changed the process model and deployed it in a version 2. I just added another usertask. After deployment, I started the migration:
2

After migration, I was directly transferred into the model view of my V2, seeing the successfully deployed instance. So far so good.
3

Now, I improved the model by adding a check on a process variable which did not exist in previous versions:
6
Well, migration worked, but as you can imagine, after completing usertask 2, I was left with this message:
4
Don’t panic! This is not an migration error, but a normal process-model-isn’t-very-sophisticated-error. The instance just rolled back to the last transaction – usertask 2. After adding the demanded variable (simply use cockpit/tasklist) the process instance ran just fine.

As you might have noticed, I also added a service task, calling a delegate. I even used that same delegate as a execution listener on usertask 2 (event type: end) where the activity/token was waiting atm. After migrating instances to that version I successfully tested that delegate-call as well.

Then I intentionally broke the recommended limitations and tried to migrate an instance, waiting at usertask 1 to a version not containing any activity going by UserTask_1. As planned it did not work:
8
7
But hey! My instance was still not burning. The migration simply was not successfull. The instance still lived in its original version.

I am keeping on playing around with business process migration and will share new knowledge. Until then:

Short conclusion:

  • The subject of process migration is more stable than I thought
  • Adding stuff won’t break the migration (and /or instance), as long existing activities can be found in the new version as well.
  • If you mess up, you are beeing warned, the migration does not go on (no guarantee :-))
  • If you did not think about needed variables in later switches, the instance will just roll back as we are used to it (no guarantee :-)).
  • The Plug-In lets you migrate only on instance level. That means a lot of clicking but also more security.
  • Carefully check the delta between an older version and another. Find whats new and add that. Use API, Cockpit, Tasklist for variables
  • Carefully check if it is better to migrate all older versions (V1, V2) directly to the latest (V3) or to migrate from version to version (V1 -> V2 -> V3).
  • Always keep that the examples above are pretty basic. You should always test production migration with similar complexity (e.g. number of activities), before pushing the button.

Before I am going to migrate instances of productive processes, I will carefully investigate them looking for existing activities (including boundary events), variables and so on.
I will test the constellations on other stages first.
I will only do that for instances of currently implemented processes because I fear the risk of overlooking / missing details of older implementations… until customer forces me🙂

Happy migrating,

Stefan

Veröffentlicht unter Uncategorized | Kommentar hinterlassen