Hauptseite: Unterschied zwischen den Versionen

Aus BiPRO Wiki
Zur Navigation springen Zur Suche springen
VisuellWikitext
Keine Bearbeitungszusammenfassung
Zeile 7: Zeile 7:
<br>https://bipro.net/
<br>https://bipro.net/


RNext stellt die nächste BiPRO Normengeneration dar und wurde in einem ersten Proof Of Concept untersucht. Aktuell gibt es verschiedene Herausforderungen im Bereich BiPRO-Implementierung. Neben einer hohen Komplexität der BiPRO-Datenmodelle, gibt es einige Hürden, die einer reibungslosen Umsetzung der BiPRO-Normen und somit einem flächendeckenden Ausrollen im Wegen stehen.  
RNext stellt die nächste BiPRO Normengeneration dar und wurde Anfang 2018 in einem ersten Proof Of Concept untersucht. Aktuell gibt es verschiedene Herausforderungen im Bereich BiPRO-Implementierung. Neben einer hohen Komplexität der BiPRO-Datenmodelle gibt es einige Hürden, die einer reibungslosen Umsetzung der BiPRO-Normen und somit einem flächendeckenden Ausrollen im Wegen stehen.
 
Hier sind einige Lösungsansätze, die im Rahmen der ersten RNext-Labs realisiert werden sollen:  
Hier sind einige Lösungsansätze, die im Rahmen der ersten RNext-Labs realisiert werden sollen:  


== Artefakte als Basiskomponente bereitstellen ==
== Artefakte als Basiskomponente bereitstellen ==


Bis dato wurden BiPRO-Normen hauptsächlich, als eine Art Richtlinie bereitgestellt. Es gibt zwar Artefakte in Form von *.eap(UML) evtl. sogar WSDL. Allerdings müssen sicht die Implementierter selbst um die Erstellung von Datenmodellen bzw. der Serviceschicht kümmern. Dabei gibt es viele Interpretationsspielräume, sodass eine einhundertprozentige BiPRO-Konformität nicht ohne weiteres zu leisten ist.  
Bis dato werden BiPRO-Normen hauptsächlich als eine Art Richtlinie bereitgestellt. Es gibt zwar Artefakte in Form eines EA-Projektes (*.eap, UML) bzw. daraus generierter XML-Schemas, sowie WSDL-Vorlagen, allerdings müssen sich die Implementierer selbst um Serialisierung und Adaption der Datenmodelle bzw. um die Erstellung der Service-Schicht kümmern. Dabei gibt es Interpretationsspielräume, sodass eine hundertprozentige BiPRO-Konformität nicht ohne Weiteres hergestellt werden kann.
Die Idee von RNext ist vor allem, dass BiPRO-Normen mit konkreten Artefakten ausgeliefert wird. Diese wiederum können sowohl den Implementierungsaufwand reduzieren, als auch die Normenkonformität steigern. Da alle Datenmodelle und die Service Endpoints genormt sind, kann man die Framework spezifischen Basiskomponenten generieren und diese in Public oder Private Package-Repositories veröffentlichen.  
 
Somit kann der Implementierer eine BiPRO-Basis, als Package für das jeweilige Programmierframework beziehen und muss lediglich die Domainspezifik als Delta implementieren. Der Implementierungsaufwand wird dadurch deutlich reduziert. Und die Norm wird maximal eingehalten.  
Die Idee von RNext dagegen ist, dass BiPRO-Normen mit konkreten Artefakten ausgeliefert werden. Diese wiederum können sowohl den Implementierungsaufwand reduzieren als auch die Normkonformität verbessern. Da alle Datenmodelle und die Service-Endpunkte normiert sind, können Framework-spezifische Basiskomponenten generiert werden und diese in public oder private Package-Repositories veröffentlicht werden. Somit kann der Implementierer eine BiPRO-Basis, als Package für das jeweilige Programmierframework beziehen und muss lediglich Spezifika der Domäne als Delta implementieren. Der Implementierungsaufwand wird dadurch deutlich reduziert. Und die Norm wird maximal eingehalten. Es sollen kleine, atomare Artefakte generiert werden, sodass der Anwender, je nach Zweck, nur den tatsächlich benötigten Funktionsumfang in seiner Anwendung nutzen kann.
Es sollen kleine, atomare Artefakte generiert werden, sodass der Anwender, je nach Zweck, nur den tatsächlich benötigten Funktionsumfang in seiner Anwendung nutzen kann.  


== WEB API / REST Service ==
== WEB API / REST Service ==
Auch wenn eine BiPRO-Norm als ein technologieübergreifendes Konstrukt angedacht ist, so ist eine gewisse Nähe zum SOAP-Protokoll unverkennbar. Im Laufe der vergangenen Jahre haben sich allerdings die technischen Rahmenbedingungen massiv verändert. Heute werden immer häufige REST Services als Web-APIs eingesetzt. Diese ermöglichen ein schlankeres Übertragungsformat in Form von JSON Daten. Des Weiteren können die komplexen Datenstrukturen in kleineren atomaren Lese- und Schreibeoperationen verarbeiten. Dabei werden vor allem die SOA Prinzipien durch die Verwendung der Micro Service Patterns ergänzt.  
 
Eine der wesentlichen Herausforderungen ist es, die BiPRO-Norm für den aktuellen und den zukünftigen Stand der Technik fit zu machen.
Auch wenn eine BiPRO-Norm als ein technologie-übergreifendes Konstrukt angedacht ist, so ist die Nähe zum SOAP-Protokoll unverkennbar. Im Laufe der vergangenen Jahre haben sich allerdings die technischen Rahmenbedingungen massiv verändert. Heute werden immer häufige REST-Services als Web-APIs eingesetzt. Diese ermöglichen ein schlankeres Übertragungsformat in Form von JSON-Daten. Des Weiteren können die komplexen Datenstrukturen in kleineren atomaren Lese- und Schreiboperationen verarbeitet werden. Dabei werden die SOA-Prinzipien durch die Verwendung von Micro Service Patterns ergänzt.
Es gibt immer mehr Clients, vor allem im Mobilen Bereich, die ausschließlich auf REST-Services setzen. Vor allem mit Hilfe der Open API Spezifikationen werden die heutigen Service Schnittstellen definiert:
 
https://github.com/OAI/OpenAPI-Specification
Eine der wesentlichen Herausforderungen ist es, die BiPRO-Norm für den aktuellen und den zukünftigen Stand der Technik fit zu machen. Es gibt immer mehr Clients, vor allem im mobilen Bereich, die ausschließlich auf REST-Services setzen. Vor allem mit Hilfe der Spezifikationen von Open API werden moderne Service-Schnittstellen definiert.
https://www.openapis.org/
 
Damit wird ermöglicht, die Schnittstellen und die dazugehörigen Datenmodelle deklarativ nach einem technologieübergreifenden Standard zu modellieren. Ein Großteil des anwendungsspezifischen Codes wird dabei durch die Generatoren erzeugt. Die Technologien, wie z.B. RAML oder SWAGGER, haben sich bereits als ein nachhaltiges aktives Ökosystem in diesem Bereich erfolgreich etabliert.  
* https://github.com/OAI/OpenAPI-Specification
* https://www.openapis.org/
 
Damit wird ermöglicht, die Schnittstellen und die dazugehörigen Datenmodelle deklarativ nach einem technologie-übergreifenden Standard zu modellieren. Ein Großteil des anwendungsspezifischen Codes wird dabei durch Generatoren erzeugt. Technologien wie RAML oder Swagger haben sich bereits als nachhaltiges aktives Ökosystem in diesem Bereich erfolgreich etabliert.


== BiPRO Datenmodelle ==
== BiPRO Datenmodelle ==
Einen Großteil der BiPRO-Normen stellen die objektorientierten Datenmodelle dar. Genaugenommen besteht das Datenmodell aus einem generischen spartenübergreifenden Teil und aus den jeweiligen spartenspezifischen Ausprägungen.  
 
Vor allem auf der Konsumentenseite ist die Anbindung einer BiPRO-Schnittstelle immer noch eine große Herausforderung. Um z.B. fünf Felder an den Service zu schicken, müssen oft komplexe Objektbäume instanziert werden, damit anschließend das hierarchische Konstrukt mit den eigentlichen Daten befüllt werden kann.
Einen wesentlichen Teil der BiPRO-Normen stellen die objektorientierten Datenmodelle dar. Das Datenmodell besteht aus generischen sparten-übergreifenden Bestandteilen und aus sparten-spezifischen Ausprägungen. Vor allem auf der Consumer-Seite ist die Anbindung einer BiPRO-Schnittstelle immer noch eine große Herausforderung. Um z.B. fünf Felder an den Service zu schicken, müssen oft komplexe Objektbäume instanziert werden, damit das hierarchische Konstrukt anschließend mit den eigentlichen Daten befüllt werden kann.
RNext soll die Komplexität solcher hierarchischeren Datenmodelle reduzieren, sodass die Anbindung von BiPRO-Services einfacher und intuitiver werden soll.  
 
RNext soll die Komplexität solcher hierarchischeren Datenmodelle reduzieren, sodass die Anbindung von BiPRO-Services einfacher und intuitiver erreicht werden kann.


== Continuous Integration/Deployment ==
== Continuous Integration/Deployment ==
CI/CD, sind in der heutigen Welt der Softwareentwicklung feste Bestandteile des ALM Prozesses. Damit, wird eine dezentrale Entwicklung, einfachere Versionierung und vor allem kürzere Release Zyklen ermöglicht.  
 
Eine der Ideen von RNext ist der Aufbau so einer zentralen Build-/Deploymentpipeline mit Hilfe eines CI/CD Servers, wie z.B. Jenkins oder TFS.
CI/CD sind in der heutigen Welt der Softwareentwicklung feste Bestandteile des Application Lifecycle Management (ALM). Damit wird eine dezentrale Entwicklung, einfachere Versionierung und vor allem kürzere Release-Zyklen ermöglicht.
 
Eine der Ideen von RNext ist der Aufbau einer solchen zentralen Build- und Deployment-Pipeline mit Hilfe eines CI/CD-Servers, wie z.B. Jenkins oder Team Foundation Server (TFS).


== BiPRO Norm Lifecycle Management ==
== BiPRO Norm Lifecycle Management ==
Der Normierungsprozess könnte wie gewohnt mit dem Erstellen des Datenmodells im EA beginnen und mit dem publizieren der Artefakte in die entsprechende Package-Repositories enden.
 
Am Ende des Normierungsprozesses stehen alle Normen in Form von verschiedenen Artefakten dem Implementierer zur Verfügung. Der Implementierungsaufwand reduziert sich erheblich, da man die BiPRO-spezifischen Komponenten nicht mehr programmieren muss. Die Norm wird dabei maximal eingehalten, da die äußerste Schicht des Services bzw. des Konsumenten immer gleichbleibt.  
Der Normierungsprozess beginnt mehr oder weniger wie gewohnt mit der Erstellung eines Datenmodells und endet mit der Publizierung der Artefakte in Package-Repositories. Am Ende des Normierungsprozesses stehen alle Normen in Form von verschiedenen Artefakten dem Implementierer zur Verfügung. Der Implementierungsaufwand reduziert sich erheblich, da die BiPRO-spezifischen Komponenten nicht mehr implementiert, sondern nur integriert werden müssen. Die Norm wird maximal eingehalten, da die äußerste Schicht des Services bzw. der Consumer-Applikation immer gleich bleiben.  
Wenn man die Artefakte in den Public Repositories publiziert, dann hat man den Vorteil, dass ein Ökosystem mit verschiedenen BiPRO Tools entsteht. Dieses Ökosystem sorgt wiederum für eine breite Akzeptanz der BiPRO-Norm und für eine nachhaltige Weiterentwicklung durch die Community.
 
Die Publikation der Artefakte in public Repositories hat den Vorteil, dass ein Ökosystem mit verschiedenen BiPRO-Tools entsteht. Dieses Ökosystem sorgt wiederum für eine breite Akzeptanz der BiPRO-Norm und für eine nachhaltige Weiterentwicklung durch die Community.
 


= FAQ zu RNext =
= FAQ zu RNext =
Zeile 71: Zeile 79:
== Design Principles ==
== Design Principles ==


=== Use before Re-use ===
BiPRO-RNext - Design Principles (Thesenpapier, April 2017)
Jedes Element eines Normierungsartefaktes (Attribute) muss praktisch eingesetzt und
verstanden werden, bevor es Teil der Norm wird (Inkubationsphase); kein Front-UpEngineering
(Overhead, Komplexität, Mismatch mit der Realität).


=== Ein digitaler Standard ist Software ===
* [[RNextDesignPrinciples|Wiki-Version]]
Die Erzeugung von reinen Papiernormen erzeugt keinen Mehrwert für die Digitalisierung
* [[Media:BiPRO-RNext-Design-Principles.pdf|PDF-Dokument]]
unserer Branche.
Regellogik, die heute in den Normen oder im Datenmodell als Prosa beschrieben ist, kann
durch Regeln in ausführbaren Code (also Beschreibung durch eine Programmiersprache)
überführt werden. Diese Logik ist dann interpretationsfrei und kann direkt in den Consumerund
Provider-Implementierungen genutzt werden.
Die Wahl der konkreten Beschreibungssprache sollte sich am Markt-Mainstream orientieren,
ist aber nicht die entscheidende Frage, weil auch heute die Übersetzungsarbeit von Prosa in
Programmlogik in jeder Implementierung erfolgen muss, d.h. das Konzept führt auf keinen
Fall zu einer Verschlechterung der Situation.
=== Modularisierung - Domain Driven Design ===
Normen und ihre Artefakte werden domain-spezifisch beschrieben und ausgerollt. Die
Artefakte können eigenständig weiterentwickelt werden. Dieses fachliche Design bietet
demnach die Grundlage für die Entwicklung von Microservices.
Normierungsartefakte, die tatsächlich in unterschiedlichen Domänen wiederverwendet
werden können, werden in ein Basismodell verschoben. Dies bedeutet de facto die Aufgabe
des Prinzips einer vollkommenen Redundanzfreiheit.
Beispiele für Domänen: Komposit vs. LV/PKV, TAA vs. Bestandsänderungen vs.
Schadenprozesse.
=== Lokale Erweiterungen (DE-AT) ===
Für die Ableitung in den lokalen Märkten, werden länderspezifische Normierungsartefakte in
eine lokale Erweiterung des Standards verschoben.
Dieses Prinzip kann domänen- und prozessspezifisch angewandt werden (d.h. der
Schieberegler für Global und Lokal kann unterschiedlich gesetzt werden): Deutschland und
Österreich haben viele grundlegende Gemeinsamkeiten, aber viele Unterschiede im Detail.
Zu den Unterschieden gehören andere Datentypen, wie Schlüssellisten, oder andere Regeln,
wie die Länge einer VSNR. Unterschiedlich sind aber auch gesetzliche Anforderungen
(anderes VVG) und länderspezifische Produkte (z.B. Riester etc.).
Daher sollte das Basisdatenmodell kontextlos sein. Das Basis-DM sollte für DE und AT
identisch sein und durch abgeleitete Datenmodelle mit Kontext ergänzt werden.
=== Trennung von Technik und Fachlichkeit ===
Die notwendigen technischen Basisstandards orientieren sich an der faktischen Begebenheit
in der fachlichen Domäne oder dem Prozess (vgl. IoT-Protokolle versus Nutzung von MQ in
Schadennetzwerken). Eine allgemeine Zukunftsprognose der Formate und Protokolle ist
herausfordernd (vgl. Trend zu asynchroner Kommunikation in Microservices).
Das heißt: Wir sehen potentiell unterschiedliche technische Protokoll-Stacks für
unterschiedliche Domänen vor, wobei wir am Ziel festhalten, die Anzahl der Stacks auf das
notwendige Mindestmaß zu reduzieren.
=== Technik beschreibt Interoperabilitätsprinzipien eines kompletten Services, nicht nur Standardisierungsprinzipien der Schnittstelle ===
Wesentliches Merkmal digitaler Standards ist die Fähigkeit, mit anderen Ökosystemen
interoperabel agieren zu können. Dies bedeutet eine Reduktion auf den absoluten
Marktmainstream der digitalen Kommunikation und die breite Unterstützung dieser Prinzipien
durch Open Source Software. Ein wesentliches Grundprinzip für die Service-Implementierung
ist die Einhaltung von Cloud-native Prinzipien (beispielsweise 12-Factor App). Da davon
auszugehen ist, dass die Geschwindigkeit der technischen Innovation mindestens die
Geschwindigkeit hält, ist ein agiler Standard die Voraussetzung, um im Markt bestehen zu
können.
=== Agiles Normierungs-Setup ===
Agile Team-Aufstellung = Product Owner, Designer und Entwickler (DevOp) per
Product
Wie passt das zu unserem Gremien-Setup des Vereins (vgl. Entwicklungen in der Allianz
oder Nürnberger die Linienhierarchie aufzugeben)?
Wir benötigen verstärkt auch nebenläufige Normierungsprozesse, um die
Marktgeschwindigkeit zu halten (vgl. Open Source Entwicklungsprojekte auf Basis Github)
“Governance by contribution” -> Mitmachen!
=== Agiles Release-Management ===
Domain-spezifische Normen können in sehr kleinen Inkrementen (Sprints) ausgerollt werden.
Durch die agile Software-Entwicklung gibt es die Forderung nach einer sehr kurzfristigen
Bereitstellung von Sub-Releases mit benötigten Change Requests.


Quelle:
* [[Media:BiPRO-RNext-Design-Principles.pdf|BiPRO-RNext - Design Principles]] (Thesenpapier, April 2017, PDF-Dokument)


= Realisierung von RNext =
= Realisierung von RNext =
Um RNext in der vollen Gänze zu verstehen, ist es sinnvoll dieses in drei Komponenten zu unterteilen.       
 
Bei RNext geht es nicht nur um die Artefakte und ihre Form, sondern auch um den Prozess, in dem sie erstellt werden. Deshalb ist es sinnvoll das gesamte Projekt in drei Komponenten zu unterteilen.       


== Organisatorisch ==
== Organisatorisch ==
Organisatorische Komponente, die sich vor allem mit folgenden Themenpunkten beschäftigt.
Organisatorische Komponente, die sich vor allem mit folgenden Themenpunkten beschäftigt.
=== Projekt/Lab/DiO-Vorgehen ===
* Vorgehen Projekt/Lab/DiO
=== Gremien/Teams Koordination ===
* Koordination Gremien/Teams


== Fachlich ==
== Fachlich ==
FachlicheKomponente, die sich vor allem mit folgenden Themenpunkten beschäftigt.
Fachliche Komponente, die sich vor allem mit folgenden Themenpunkten beschäftigt.
=== Domänenschnitte ===
* Domänenschnitte
=== Migration von RClassic auf RNext ===
* Migration von RClassic nach RNext


== Technisch ==
== Technisch ==
TechnischeKomponente, die sich vor allem mit folgenden Themenpunkten beschäftigt.
Technische Komponente, die sich vor allem mit folgenden Themenpunkten beschäftigt.
=== Authentifizierung ===
* Authentifizierung
=== Buildpipeline ===
* Buildpipeline
 


= Ergebnisse der Arbeitsgruppe RNext =
= Ergebnisse der Arbeitsgruppe RNext =

Version vom 5. November 2018, 11:38 Uhr

Was ist RNext?

BiPRO-RNext oder einfach RNext ist der Codename für die nächste Release-Generation von BiPRO-Schnittstellen.

Powered by

https://bipro.net/

RNext stellt die nächste BiPRO Normengeneration dar und wurde Anfang 2018 in einem ersten Proof Of Concept untersucht. Aktuell gibt es verschiedene Herausforderungen im Bereich BiPRO-Implementierung. Neben einer hohen Komplexität der BiPRO-Datenmodelle gibt es einige Hürden, die einer reibungslosen Umsetzung der BiPRO-Normen und somit einem flächendeckenden Ausrollen im Wegen stehen.

Hier sind einige Lösungsansätze, die im Rahmen der ersten RNext-Labs realisiert werden sollen:

Artefakte als Basiskomponente bereitstellen

Bis dato werden BiPRO-Normen hauptsächlich als eine Art Richtlinie bereitgestellt. Es gibt zwar Artefakte in Form eines EA-Projektes (*.eap, UML) bzw. daraus generierter XML-Schemas, sowie WSDL-Vorlagen, allerdings müssen sich die Implementierer selbst um Serialisierung und Adaption der Datenmodelle bzw. um die Erstellung der Service-Schicht kümmern. Dabei gibt es Interpretationsspielräume, sodass eine hundertprozentige BiPRO-Konformität nicht ohne Weiteres hergestellt werden kann.

Die Idee von RNext dagegen ist, dass BiPRO-Normen mit konkreten Artefakten ausgeliefert werden. Diese wiederum können sowohl den Implementierungsaufwand reduzieren als auch die Normkonformität verbessern. Da alle Datenmodelle und die Service-Endpunkte normiert sind, können Framework-spezifische Basiskomponenten generiert werden und diese in public oder private Package-Repositories veröffentlicht werden. Somit kann der Implementierer eine BiPRO-Basis, als Package für das jeweilige Programmierframework beziehen und muss lediglich Spezifika der Domäne als Delta implementieren. Der Implementierungsaufwand wird dadurch deutlich reduziert. Und die Norm wird maximal eingehalten. Es sollen kleine, atomare Artefakte generiert werden, sodass der Anwender, je nach Zweck, nur den tatsächlich benötigten Funktionsumfang in seiner Anwendung nutzen kann.

WEB API / REST Service

Auch wenn eine BiPRO-Norm als ein technologie-übergreifendes Konstrukt angedacht ist, so ist die Nähe zum SOAP-Protokoll unverkennbar. Im Laufe der vergangenen Jahre haben sich allerdings die technischen Rahmenbedingungen massiv verändert. Heute werden immer häufige REST-Services als Web-APIs eingesetzt. Diese ermöglichen ein schlankeres Übertragungsformat in Form von JSON-Daten. Des Weiteren können die komplexen Datenstrukturen in kleineren atomaren Lese- und Schreiboperationen verarbeitet werden. Dabei werden die SOA-Prinzipien durch die Verwendung von Micro Service Patterns ergänzt.

Eine der wesentlichen Herausforderungen ist es, die BiPRO-Norm für den aktuellen und den zukünftigen Stand der Technik fit zu machen. Es gibt immer mehr Clients, vor allem im mobilen Bereich, die ausschließlich auf REST-Services setzen. Vor allem mit Hilfe der Spezifikationen von Open API werden moderne Service-Schnittstellen definiert.

Damit wird ermöglicht, die Schnittstellen und die dazugehörigen Datenmodelle deklarativ nach einem technologie-übergreifenden Standard zu modellieren. Ein Großteil des anwendungsspezifischen Codes wird dabei durch Generatoren erzeugt. Technologien wie RAML oder Swagger haben sich bereits als nachhaltiges aktives Ökosystem in diesem Bereich erfolgreich etabliert.

BiPRO Datenmodelle

Einen wesentlichen Teil der BiPRO-Normen stellen die objektorientierten Datenmodelle dar. Das Datenmodell besteht aus generischen sparten-übergreifenden Bestandteilen und aus sparten-spezifischen Ausprägungen. Vor allem auf der Consumer-Seite ist die Anbindung einer BiPRO-Schnittstelle immer noch eine große Herausforderung. Um z.B. fünf Felder an den Service zu schicken, müssen oft komplexe Objektbäume instanziert werden, damit das hierarchische Konstrukt anschließend mit den eigentlichen Daten befüllt werden kann.

RNext soll die Komplexität solcher hierarchischeren Datenmodelle reduzieren, sodass die Anbindung von BiPRO-Services einfacher und intuitiver erreicht werden kann.

Continuous Integration/Deployment

CI/CD sind in der heutigen Welt der Softwareentwicklung feste Bestandteile des Application Lifecycle Management (ALM). Damit wird eine dezentrale Entwicklung, einfachere Versionierung und vor allem kürzere Release-Zyklen ermöglicht.

Eine der Ideen von RNext ist der Aufbau einer solchen zentralen Build- und Deployment-Pipeline mit Hilfe eines CI/CD-Servers, wie z.B. Jenkins oder Team Foundation Server (TFS).

BiPRO Norm Lifecycle Management

Der Normierungsprozess beginnt mehr oder weniger wie gewohnt mit der Erstellung eines Datenmodells und endet mit der Publizierung der Artefakte in Package-Repositories. Am Ende des Normierungsprozesses stehen alle Normen in Form von verschiedenen Artefakten dem Implementierer zur Verfügung. Der Implementierungsaufwand reduziert sich erheblich, da die BiPRO-spezifischen Komponenten nicht mehr implementiert, sondern nur integriert werden müssen. Die Norm wird maximal eingehalten, da die äußerste Schicht des Services bzw. der Consumer-Applikation immer gleich bleiben.

Die Publikation der Artefakte in public Repositories hat den Vorteil, dass ein Ökosystem mit verschiedenen BiPRO-Tools entsteht. Dieses Ökosystem sorgt wiederum für eine breite Akzeptanz der BiPRO-Norm und für eine nachhaltige Weiterentwicklung durch die Community.


FAQ zu RNext

Hier gibt es eine lange Liste von FAQs rund um das Thema RNext. Die BiPRO-Geschäftsstelle, sowie die Arbeitsgruppe RNext versuchen diese Sammlung stets up-to-date zu halten: FAQs.


Tools in RNext

OpenAPI Specification 3.0

In früheren Version synonym mit Swagger. Ist eine Spezifikation zur Beschreibung von RESTful Webservices in RAML (RESTful API Modeling Language). Das Tool Swagger kann online verwendet werden oder als Client heruntergeladen werden. Hier der Link zur Online-Version: https://editor.swagger.io

GitLab

https://gitlab.rnext.org

Jenkins

https://jenkins.rnext.org

Nexus

https://nexus.rnext.org


Onboarding für Mitglieder der Arbeitsgruppe RNext

Hilfe zur Benutzung und Konfiguration der Wiki-Software findest du im Benutzerhandbuch.


Grundlagen

Design Principles

BiPRO-RNext - Design Principles (Thesenpapier, April 2017)


Realisierung von RNext

Bei RNext geht es nicht nur um die Artefakte und ihre Form, sondern auch um den Prozess, in dem sie erstellt werden. Deshalb ist es sinnvoll das gesamte Projekt in drei Komponenten zu unterteilen.

Organisatorisch

Organisatorische Komponente, die sich vor allem mit folgenden Themenpunkten beschäftigt.

  • Vorgehen Projekt/Lab/DiO
  • Koordination Gremien/Teams

Fachlich

Fachliche Komponente, die sich vor allem mit folgenden Themenpunkten beschäftigt.

  • Domänenschnitte
  • Migration von RClassic nach RNext

Technisch

Technische Komponente, die sich vor allem mit folgenden Themenpunkten beschäftigt.

  • Authentifizierung
  • Buildpipeline


Ergebnisse der Arbeitsgruppe RNext


Starthilfen

Abgerufen von „https://wiki.bipro.net/index.php?title=Hauptseite&oldid=65“