Visma-Schnittstelle und API-Integration
Visma ist eine Softwaregruppe aus Oslo, die durch Zukäufe über Europa gewachsen ist, und die gekauften Produkte laufen unter ihren eigenen Namen weiter, mit eigener Produktarchitektur und eigenem Zugang. Maesn unterstützt jedes davon als eigene Integration, und jedes angebundene System antwortet auf dieselbe REST API.
Drei Kosten einer Visma-Anbindung, die hier aufhören
Mehr als ein Visma-Produkt anzubinden ist nicht eine Integration, zweimal gemacht. Hier steht, was jedes Produkt für sich kostet, und was an dieser Schicht endet.
Ein Verbindungsablauf statt eines je Produkt
Visma e-conomic gibt ein einziges AppSecretToken aus und paart es bei jeder Anfrage mit einem Grant-Token je Kunde. Visma eAccounting schickt Ihnen Client-ID und Secret per E-Mail, will daneben einen Abonnementschlüssel und lässt Sie die Callback-URL nicht selbst setzen. Holded hat keinen OAuth-Redirect und arbeitet mit einem Schlüssel, den der Kunde erzeugt. Unter Maesn kommen sie als ein Account-Key heraus.
Welches Visma ein Kunde einsetzt, ist ein Nachschlagen und keine Recherche
Dasselbe eAccounting-System wird in Schweden als Spiris und in Norwegen und den Niederlanden als eAccounting verkauft, während die finnischen Produkte im Portfolio gar kein eAccounting sind und auf eigenen APIs laufen. Ein Interessent, der sagt, er sei auf Visma, hat Ihnen den Konzern genannt und nicht das System. Maesn hält diese Zuordnung. Die Antwort wird also ausgewählt statt recherchiert.
Drei Visma-Märkte testen, ohne drei Projekte zu fahren
Eine Sandbox-Firma von Visma eAccounting gehört zu einer Region, und die Region lässt sich danach nicht mehr ändern. Jedes Visma-Konto trägt genau eine. Einen zweiten Markt zu testen heißt also, ein zweites Konto unter einer anderen E-Mail-Adresse zu registrieren. Maesn macht diese Arbeit, und was Sie bekommen, ist eine Verbindung, die sich gleich verhält, aus welchem Markt sie auch kommt.
In Ihrem Code kommen ein REST-Aufruf und ein Account-Key an. Welches Visma-Produkt ein Kunde einsetzt, wird zu einem Konfigurationswert, und der nächste Visma-Markt ist eine kommerzielle Entscheidung und keine technische.
Ein kurzes Gespräch genügt meist, um zu klären, welches Visma-Produkt Ihre Kunden einsetzen.
Drei Gründe, die Visma-Schnittstelle über Maesn anzubinden
Visma kauft Software und lässt sie unter ihrem eigenen Namen weiterlaufen. Das Portfolio ist deshalb eine Liste von Produkten und keine Produktlinie. Hier sehen Sie, wo jedes einzelne bei Maesn gerade steht.
Von den Produkten oben sprechen 8 heute die Maesn API an, auf 7 Zielsystemen, weil Spiris und Visma eAccounting eine Verbindung unter zwei Namen sind. Die übrigen stehen hier, weil ein Portfolio dieser Breite Teil der Entscheidung ist, und weil zu wissen, welches Produkt ein Markt einsetzt, die Arbeit vor der Integration ist.
Eine Visma-API deckt drei Märkte unter drei verschiedenen Namen
Von der Regel, dass jedes Visma-Produkt ein eigenes System ist, gibt es eine Ausnahme, und das ist die eAccounting-Familie. Dasselbe Zielsystem wird in jedem seiner Märkte unter einer anderen Marke verkauft. Eine Anbindung, die für eines davon gebaut ist, erreicht damit auch die übrigen.
- SchwedenSpiris
Früher SPCS, und der Grund, warum ein schwedischer Kunde den Namen eAccounting nicht kennt.
- NorwegenVisma eAccounting
Heute im Verzeichnis, und der Markt, auf den der Link zur kostenlosen Testphase zeigt.
- NiederlandeVisma eAccounting
Heute im Verzeichnis, und der zweite Markt auf denselben Zugangsdaten.
Praktisch heißt das: Ein schwedischer Interessent auf Spiris und ein norwegischer auf Visma eAccounting sind für Sie dieselbe Integration. Zu bestätigen bleibt je Markt die Ebene der Endpunkte, weil die Verfügbarkeit nicht in allen gleich ist.
Mit dem Portfolio darum herum verhält es sich anders: Visma kauft Software und belässt jedes Produkt auf seiner eigenen Schnittstelle, ein Anbieterlogo kann also weiterhin mehrere zusammenhanglose Integrationen bedeuten. Wo ein Portfolio so zersplittert ist, verhindert ein Common Data Model, dass aus einem neuen Markt eine neue Codebasis wird.
Sagen Sie uns Land und Produkt, und wir bestätigen, was heute möglich ist.
Findity bettet den Ausgabenabgleich in die Produkte seiner Partner ein
Findity ist eine Plattform für die Ausgabenverwaltung, die White-Label- und API-Produkte verkauft. Ihre Buchhaltungsintegrationen werden also in der Software anderer ausgeliefert statt in der eigenen.
“Maesn hat uns geholfen, Integrationen zu Buchhaltungssystemen zu bauen, und wir können uns dadurch auf andere Prioritäten in unserer Roadmap konzentrieren. Besonders schätzen wir die Unterstützung, die wir jedes Mal bekommen haben, wenn wir erweiterte Funktionen in einer Integration brauchten, die Maesn für uns eingerichtet hat.”
Drei Gründe, die Visma-Schnittstellen über Maesn anzubinden
Eine einzelne Visma-Integration in einen einzelnen Markt ist eine normale Integration. Die Kosten tauchen beim zweiten Produkt auf, denn das zweite Produkt teilt mit dem ersten einen Mutterkonzern und sonst fast nichts.
Die Produktrecherche endet hier
Welches Visma-System in welchem Markt läuft, wie es dort heißt, auf welcher API es sitzt und was es Ihnen bei der Registrierung aushändigt, ist die Arbeit vor der Arbeit. Maesn trägt sie, und sie wird nicht neu gemacht, wenn der nächste Interessent sagt, er sei auf Visma.
Die Unterschiede enden an dieser Schicht
Zwei Modelle für Zugangsdaten, zwei Modelle für das Blättern und je Produkt ein eigenes Partnerverfahren, alle beantwortet über einen Account-Key und ein Datenmodell. Welches Visma ein Kunde betreibt, bleibt ein Konfigurationswert in Ihrem Code statt einer zweiten Umsetzung.
Eine Integration, und sie gilt nicht nur für Visma
Dieselbe Schnittstelle, die Visma e-conomic erreicht, erreicht über 30 weitere ERP- und Buchhaltungssysteme. Das Visma-Portfolio wächst auf unserer Seite und nicht in Ihrer Codebasis, und alles daneben ebenso.
Jedes Visma-Produkt führt einen eigenen Marketplace
Die meisten Anbieter hören bei der API auf. Maesn übernimmt die technische Seite und den Eintrag, und bei Visma ist der Eintrag nicht ein Eintrag: Jedes Produkt betreibt seinen eigenen Marketplace mit eigenem Publikum. Das Verfahren wird also je Produkt angestoßen statt einmal für die Gruppe.
Technische Unterstützung
Eine Integration gegen die Unified API und ein Datenmodell, identisch über die Visma-Produkte hinweg und über alles andere, was Maesn unterstützt. Ihre Entwickler treffen auf eine Schnittstelle und nicht auf eine je Produkt.
Unterstützung bei der Partnerschaft
Maesn stößt das Eintragsverfahren für das jeweilige Produkt an, in dem Markt, in dem dieses Produkt tatsächlich verkauft wird, und unterstützt das Co-Marketing, das dazugehört. Der Eintrag trägt den Namen Ihres Produkts, nicht unseren.
Je Produkt, nicht je Gruppe
Visma e-conomic betreibt einen eigenen App-Marketplace und Visma eAccounting einen getrennten. Im einen gelistet zu sein sagt nichts über den nächsten, und das ist dieselbe Zersplitterung, die auch die API-Seite hat.
In der Praxis je Markt
Die Produkte werden in verschiedenen Ländern unter verschiedenen Namen verkauft, und das Publikum eines Marketplace ist das Publikum dieses Marktes. Ein Produkt, das in Dänemark und Schweden live ist, hat vor zwei verschiedenen Gruppen von Kunden gestanden.
Co-Marketing gehört dazu
Der Eintrag ist der Einstieg und nicht der ganze Nutzen. Was folgt, ist gemeinsame Sichtbarkeit mit dem Hersteller, und in einem so zersplitterten Portfolio ist das mehr wert als ein Verzeichniseintrag, denn das Publikum wird Produkt für Produkt erreicht.
Die Integration läuft unter dem Namen Ihres Produkts, und der Eintrag gehört Ihnen und nicht uns. Maesn ist die Schicht dahinter.
Wir stoßen den Prozess für das konkrete Produkt mit Ihnen an.
Visma e-conomic und Visma eAccounting, zwei verschiedene Zugangsdatensätze
Visma e-conomic und Visma eAccounting authentifizieren auf zwei wirklich verschiedene Weisen, und genau dort hört ein gemeinsamer Mutterkonzern auf, eine gemeinsame Architektur zu bedeuten. Visma e-conomic nutzt ein eigenes Modell mit zwei Tokens statt OAuth: Ein Token weist Ihre Anwendung aus, ein zweites wird je Kunde ausgestellt. Visma eAccounting nutzt OAuth 2.0 mit vorab deklarierten Scopes. Ihr Kunde sieht so oder so einen Zustimmungsdialog, und Ihr Code sieht einen Account-Key.
- Modell mit zwei Tokens
- Visma e-conomic, App-Token plus Freigabe je Kunde
- OAuth 2.0
- Visma eAccounting, drei Werte und ein Callback, den Visma setzt
Zwei Eingänge, eine Implementierung. Maesn verwahrt beide Sätze Zugangsdaten und gibt je angebundenem Kunden einen Account-Key zurück.
- Ein Satz App-Zugangsdaten je System
- Das AppSecretToken für Visma e-conomic, und für Visma eAccounting die Client-ID, das Client Secret und der Abonnementschlüssel. Einmal eingereicht, für jeden Kunden benutzt, den Sie in diesem Markt anbinden.
- Die Tokens und ihr Lebenszyklus
- Das Grant-Token je Kunde bei e-conomic verwahrt Maesn und hängt es an jede spätere Anfrage. Bei eAccounting übernimmt Maesn außerdem das Erneuern, und das zählt, weil dieses System ein Token still ungültig macht, wenn der Nutzer sein Passwort ändert.
Die stille Entwertung bei eAccounting ist der Fehlerfall, für den sich Planung lohnt, denn sie erzeugt keinen Fehler bis zum nächsten Aufruf und gar keine Benachrichtigung. Maesn erkennt sie und legt die erneute Autorisierung offen, und das macht aus einer Integration, die still aufgehört hat zu arbeiten, eine Aufforderung, auf die Ihr Kunde reagieren kann.
- 1
Ihr Kunde startet in Ihrem Produkt
Sie schicken ihn in den Ablauf, und Maesn öffnet den Zustimmungsbildschirm des Visma-Systems, das er betreibt. Er trägt den Namen Ihrer Anwendung, denn die App ist auf Ihr Unternehmen registriert.
- 2
Er gibt einmal frei
Eine Zustimmung ist der ganze Schritt, und Maesn klärt daneben, was das System sonst braucht. Zurück kommt der Kontext, den spätere Anfragen brauchen, verwahrt an der Verbindung.
- 3
Sie arbeiten mit einem Account-Key
Maesn speichert die Verbindung und gibt einen Account-Key zurück. Jede Anfrage trägt dann Ihren Maesn-API-Schlüssel und diesen Account-Key, und nichts in Ihrem Code muss wissen, ob es ein System mit zwei Tokens erreicht hat oder eines mit OAuth.
Visma e-conomic und Visma eAccounting synchronisieren mit einem geplanten Abruf
Visma e-conomic und Visma eAccounting bleiben beide über einen geplanten Lesezugriff synchron, und der läuft, ohne jemanden zu fragen. Events werden je Objekt freigeschaltet, wenn ein Anwendungsfall eines braucht. Ein Event, auf das Ihr Produkt angewiesen ist, ist also ein Gespräch und keine Sackgasse.
Eine Änderung im Visma-Konto eines Kunden bleibt unsichtbar, bis etwas sie liest, und das gilt für die meisten Buchhaltungssysteme und ist der Grund, warum es den geplanten Lesezugriff überhaupt gibt. Wo die Events eines Objekts Ihr Produkt verändern würden, sagen Sie uns Bescheid, und wir schalten sie für dieses System frei.
Ein geplanter Lesezugriff, mit demselben Filter und derselben Paginierung auf beiden Systemen und auf allem anderen, das Sie anbinden. Der Code zur Änderungserkennung wird einmal geschrieben und auf einen anderen Account-Key gerichtet, gleich welches Visma-Produkt dahintersteht.
Darunter paginieren die beiden Systeme unterschiedlich, und das ist die Art Unterschied, die diese Schicht wegnehmen soll. Visma e-conomic paginiert über beide seiner APIs hinweg über einen Cursor, Sie können also weder zu einer Seite springen noch nach einem Offset fragen. Visma eAccounting liefert 50 Ergebnisse je Seite und gibt einen unvollständigen Satz zurück, ohne sich zu beschweren, wenn niemand nachfasst. Über Maesn antworten beide auf dasselbe Offset-Paging, und das Durchlaufen passiert auf dieser Seite.
Zwei Systeme, die unterschiedlich paginieren, müssen trotzdem vom selben Code nach demselben Zeitplan gelesen werden. Ein Weg, zu filtern und zu paginieren macht das möglich, und das Event-Modell ist der Ort, an dem ein Visma-Objekt landet, sobald eines dieser Events eingeschaltet wird.
Was eine Visma-Anbindung braucht, vor dem ersten Aufruf
Was eine Visma-Integration vor dem ersten Aufruf braucht, hängt davon ab, welches Visma es ist. Vier Dinge gelten über die angebundenen hinweg, und alle vier liegen auf der Kundenseite der Linie und nicht in Ihrem Code.
- Ein aktives Konto, je Produkt
- Beide Systeme nennen das als ihre gesamte Voraussetzungsliste: ein aktives Visma-e-conomic-Konto oder ein aktives Visma-eAccounting-Konto. Das sollte man im Qualifizierungsgespräch bestätigen, denn ohne eines gibt es nichts anzubinden.
- Ein eigener Antrag, je Produkt registriert
- Für Visma e-conomic legen Sie eine App im Entwicklerportal an und tragen die Callback-URL von Maesn selbst ein. Bei Visma eAccounting kommen die Zugangsdaten bei der Registrierung per E-Mail, und die Callback-URL ist der Teil, den Sie nicht setzen können: Sie müssen Visma bitten, sie zu ändern.
- Die Zugangsdaten, einmal übergeben
- Visma e-conomic braucht das AppSecretToken, bei Maesn eingereicht. Visma eAccounting braucht Client-ID, Client Secret und Abonnementschlüssel. Einmal eingereicht, danach für jeden Kunden benutzt, den Sie anbinden.
- Ein Sandbox-Konto je Region, die Sie testen wollen
- Beide Systeme bieten ein kostenloses Testkonto an, und darauf läuft ein Machbarkeitsnachweis. Bei eAccounting steht die Region fest, sobald die Sandbox-Firma angelegt ist, und eine produktive Client-ID erreicht eine Sandbox-Firma, während eine Sandbox-Client-ID die Produktion nie erreicht.
Wir gehen die Registrierung für jedes Produkt mit Ihnen durch.
