Closed mmhaven closed 4 months ago
Sorry for that. Did not realize that it would have such an impact, but I wanted to do that for years already. The good news is that the interface is stable now. You could write a transformer that can transform request messages from version 2.17 to 2.18 and vice versa for the response messages (you could use XSLT for that). Then you could upgrade and expose 2 endpoints: 1 with the new 2.18 interface and 1 with the 2.17 interface that transforms the messages. You could also expose 1 endpoint and use a content based router to route to either one. Another option (depending on your configuration) would to run 2.17 and 2.18 in parallel, because they run on the same database model. But this holds only for version 2.18, because 2.19 (that will be released soon and runs on java 11) will have database changes.
Or we could try to make the 2.17 interface available again in version 2.19 next to the 2.18 interface, if this is really necessary. We would rather not take this route, because it takes extra time and code, and we are busy to cleanup the code.
If the database model between 2.17 and 2.19 is different it would indeed mean a lot of overhead if solved in a code-wise manner. I'll have to discuss internally what way forward we can follow (probably the transformation route), but also double check how other ART's in the organisation use ebMS / Digikoppeling. I'll keep you posted.
Btw, I did not see it well, but there are some database changes in version 2.18 as well (a few tables where renamed), so you cannot migrate through 2.18 with the same database.
Thanks for that heads-up. We're exploring the original idea of two end-points where one is pretty much the 'front' for the other (i.e. the XSLT or something compatible that you mentioned). Let's see of such a façade can be made part of this code base as an open source contribution (I have to deal with red-tape though)
I want to take a look this week if I can integrate the 2.17 interface into the application. Could you let me know which interfaces you expose to you suppliers? I mean the CPA, UrlMapping, CertificateMapping and/or the EbMSMessage interfaces.
We have been working with the ebMS core code for awhile, but have refrained from upgrading because of the element name updates. For example, an element like "InsertCPA" has been renamed to "insertCPA"
This is, in our case, introducing breaking changes for any user that tries to send a request for "InsertCPA" since it doesn't comply with a schema anymore. What is the best way forward for upgrading, but retaining backwards compatibility? Our 600+ suppliers that make use of the Digikoppeling connections we have take a long time to upgrade, so this is a change that has a lot of impact.