Schnittstelle für alle Fälle: 10 Infos zur Aryza-API

1. Warum bieten wir eine Anwendungsprogrammierschnittstelle (API) an?

Die API verbessert die Integrationsmöglichkeit unserer SaaS-Lösung mit bestehenden Softwareanwendungen sowohl On-Premises als auch in der Cloud. Externe Systeme haben in der Regel sehr unterschiedliche fachliche Daten und technische Spezifikationen. Der Kunde kann nun selbst oder mit einem Partner einen Integrationslayer zwischen den eigenen Schnittstellen und unserer API entwickeln. Die Komplexität wird auf diese Weise deutlich reduziert. Die API bietet zudem verschiedene Methoden, um auch hier Dateien per WebService zu transferieren. Außerdem werden durch die offenen Schnittstellen Datensilos vermieden.

2. Auf welche Daten erhalten Kunden:innen Zugriff?

Der Programmierer oder die Programmiererin auf Kundenseite kann mit unterschiedlichen fachlichen und technischen Facetten der Anwendung interagieren. Wir gewährleisten den Zugriff auf High-Level Use-Cases, wie zum Beispiel den Import und Export von Kundenstammdaten und Kreditantrags- und Forderungsdaten inkl. der dazugehörigen Fallinformationen über Konten und Sicherheiten.

• High-Level Use-Case: Das kann zum Beispiel der Befehl sein: „Gibt mir den Anredetext zu Partner xyz.“
• Low-Level Use-Case: Auch der Zugriff auf Low Level Use-Cases, wie die Abfrage einzelner Geschäftsobjekte zur Anbindung der Anwendung etwa an ERP- oder Corebanking-Systeme, Informationsdienstleister, DMS, Druckstraßen und Portale, ist gewährleistet. Das kann zum Beispiel der Befehl sein: „Gibt mir die Stammdaten des Partners xyz.“

3. Sind bei der Anbindung an die unterschiedlichen ERP-Systeme differierende Herangehensweisen notwendig; bzw. werden alle ERP-System unterstützt?

Grundsätzlich lassen sich alle gängigen ERP-Systeme an unsere Software andocken. Jedoch haben diese ERP-Systeme in der Regel unterschiedliche Anforderungen an die Technik (zum Beispiel Antwortzeiten, Verfügbarkeit, Sicherheit, Datenmengen, etc.) und an die Fachlichkeit. Oft stimmen fachliche Entitäten oder Strukturen nicht überein. In dem Kontext ist das sogenannte Daten-Mapping ein wichtiges Thema. Dabei geht es um das Verknüpfen von Feldern verschiedener Datenbanken. Das Mapping ist meist der erste Schritt für eine Datenintegration.

Darüber hinaus ist auch immer die Frage, wer „Producer“ (also Anbieter) und wer „Consumer“ einer API ist. In der Regel stellt auch das ERP-System des Kunden APIs bereit. In diesem Fall ist es Aufgabe der Integrationsschicht (Integration-Layer) eine Verbindung zwischen den Systemen als Consumer mehrerer APIs herzustellen.

4. Wie wird die Entwicklungsumgebung dargestellt?

Die API kann unabhängig von der Entwicklungsumgebung verwendet werden. Da sie auf Standardtechnologien wie HTTP und GraphQL basiert, können die WebServices mit beliebigen Programmiersprachen in bestehende oder neue Softwareprojekte eingebunden werden. Der Datentransport geschieht über HTTPS. Das Daten- und Abfrageformat wird hierbei durch ein GraphQL-Schema bestimmt. Zur Unterstützung der Entwicklung von Integrationen bieten wir eine Cloud-Instanz und interaktive Dokumentation an. Darüber hinaus wird ein Java SDK inkl. Beispielen angeboten, das Integratoren (Kunden oder Partner) bei der Entwicklung von Integrationsschichten in der Programmiersprache Java bestmöglich unterstützt.

5. Um welche API-Typklasse handelt es sich und wie stabil ist sie?

Wie bieten eine sogenannte Public/Partner-API an und garantieren Abwärtskompatibilität. Wir stellen also sicher, dass Weiterentwicklungen unserer API weiterhin alle Funktionalitäten der vorangegangenen Version unterstützen. Damit sinkt das Risiko für den Kunden, seine eigenen API-Anbindungen anpassen zu müssen, wenn wir unsere API weiterentwickeln. Um eine Hochverfügbarkeit der API zu gewährleisten, sehen wir in unserer Cloud-Architektur redundante Infrastrukturkomponenten vor, verteilt auf verschiedene Rechenzentren. Unsere API ist in der Cloud also selbst dann erreichbar, wenn zum Beispiel Wartungsarbeiten ausgeführt werden oder ein Rechenzentrum ausfällt.

6. Für welche Softwarelösungen ist die API gedacht?

Die API ist grundsätzlich für eine Vielzahl von Softwarelösungen gedacht, darunter Portale, Kernbankensysteme, Warenwirtschaftsysteme, Buchhaltungssysteme, Meldewesen, externe Auskunfsdienste, externe Rating- oder Entscheidungssysteme, externe WorkflowEngines, Druckstraßen und auch Telefonie-, Mail- und Dokumentenmanagementsysteme.

7. Gibt es auch Schwierigkeiten bei Nutzung der standardisierten Schnittstelle?

Bei der Verwendung der Schnittstelle muss auf Datenvolumen und Ansprachehäufigkeit geachtet werden. Besteht die Notwendigkeit, große Datenmengen zwischen On-Premises und Cloud zu transferieren, bieten wir dafür eine speziell auf Massendaten ausgelegte Schnittstelle an.

8. Welche Sicherheitsmaßnahmen setzt Aryza hier um?

Risiken bestehen in den Bereichen Datentransfer, Datenspeicherung und Datenzugriff. Der Zugriff auf die Schnittstellen wird zunächst per OAuth gesichert, die Sicherheit der Daten durch den Transport via HTTPS gewährleistet. Die Daten werden sowohl in der Datenbank als auch auf den Applikationsservern verschlüsselt abgelegt. Zugriffe auf die Infrastruktur der Cloud-Umgebung für Aryza-Mitarbeiter:innen sind basierend auf einem Rollenkonzept stark eingeschränkt und werden protokolliert.

9. Open Credit 4.0 soll als Platform as a Service-Lösung mehr Effizienz gewährleisten. Welche Aufgabe erfüllt die neue Schnittstelle in diesem Kontext?

Cloud-Computing (Download Whitepaper) bietet die einzigartige Möglichkeit, Rechenkraft bedarfsgerecht hinzu- und auch wieder abzuschalten. Genau dies kann je nach Last auf die API-Infrastruktur genutzt werden, um eine zeitgerechte Beantwortung von Anfragen zu gewährleisten. Konkret bedeutet dies, dass die Leistungsfähigkeit der API mit dem Bedarf unserer Kunden unter Wahrung der Datensicherheit mitwachsen kann.

10. Wann sollte man die Software in der Cloud und wann On-Premises betreiben?

Für viele Maßnahmen, die wir in der Cloud sicherstellen – wie Sicherheitsaspekte, Verfügbarkeit und die lastgerechte Ausstattung der IT-Infrastruktur – muss der Kunde selbst Vorkehrungen treffen, wenn er unsere Lösung lokal nutzen möchte. Aus dem Grund nehmen wir eine steigende Nachfrage nach der Bereitstellung unserer Anwendungen als SaaS wahr. Für On-Premises-Kunden werden wir unsere Anwendung und unsere Schnittstellen jedoch nach wie zur Verfügung stellen.

Glossar

• API (Application Programming Interface): Programmierschnittstelle zur Integration / Anbindung unserer Lösungen in die IT-Landschaft des Kunden.
• Integration: Programmierarbeiten zur Integration von Open Credit 4.0 in die Landschaft des Kunden.
• IL (Integration-Layer): Ergebnis der Integration.
• Java-SDK: Software Development Kit – wird zur Vereinfachung der Erstellung von Integrationsschichten verwendet.
• Inbound / Outbound: Richtung der Informationen.
• Realtime: Anfragen werden sofort verarbeitet (typischerweise < 2 – 10s)
• Near realtime: Anfragen werden asynchron oder periodisch verarbeitet, um Echtzeitanforderungen zu simulieren (typischerweise 1 – 5 min)
• Batch: Anfragen werden in einem Batch verarbeitet (typischerweise über Nacht)
• Trigger (from OC4 / from external): Anfragen werden innerhalb der OC4-Plattform ausgelöst (z.B. durch Benutzerinteraktion oder automatisierte Workflows) /
  Anfragen werden aus externen Systemen ausgelöst.