Utmaningar i Formpipe-integrationen

Att integrera mot Formpipe via deras API är minst sagt problematiskt och behöver lösas innan en uppskalning kan dras igång.

Våra erfarenheter hittills i integrationsarbetet:

• Formpipes API är byggt på en föråldrad SOAP-replika som heter WCF, inkluderande en tillhörande säkerhetslösning som inte går att implementera i Java. Deras API kräver alltså att klienten byggs i .NET, vilket absolut inte är OK ur ett interoperabilitetsperspektiv!

  • Vi bör kräva möjlighet att integrera med Formpipe via ett REST-API som följer OpenAPI-standard

• Deras WSDL-beskrivningar är dessutom felaktiga - i bästa fall går det att generera klientkod innehållande en massa varningar, men som ändå på något sätt går att få att fungera, och i andra fall så pass felaktiga att det är omöjligt att generera klientkod utan att manuellt ändra i deras gränssnittskontrakt (vilket är ohållbart ur ett förvaltningsperspektiv)

  • Som ovan, ett REST-API som följer OpenAPI-standard, och som självklart dessutom är korrekt

• Det saknas helt information i specen om vilka felkoder man kan få i svar på anrop (och de felmeddelanden vi ändå sett finns är obegripliga) vilket leder till att det är omöjligt att bygga en förvaltningsbar lösning med avseende på felhantering

  • Som ovan, ett REST-API som följer OpenAPI-standard, och med tydlig dokumentation om felkoder och felmeddelanden

• Dokumentationen innehåller uteslutande innehåller en massa C#-kod - totalt ointressant för våra team med Javautvecklare (interoperabiliteten igen)

  • Som ovan, ett REST-API som följer OpenAPI-standard löser detta

• Dessutom är designen av APIet dåligt - att lösa en så pass grundläggande och enkel sak som att kunna söka ut ett arkivpaket utifrån de paket-id´n vi får tillbaka efter en lyckad import kräver en överkomplex anropskedja mot deras API

  • Här behöver leverantören designa sitt API utifrån de användningsfall dess klienter har behov av att lösa - vad de har designat det på för grunder i dag kan man fråga sig…