Future of SuperOffice.NetServer.Services package and SOAP web services
At SuperOffice, we greatly value our ongoing partnership and collaboration with you. As we move forward on our journey to enhance and streamline our services, we wanted to provide you with an important update regarding our SOAP support.
While we understand that not all of our existing partners and integration customers will be able to make an immediate shift away from SOAP, we want to share our desire to gradually eliminate SOAP support within the next few years. This transition is part of our ongoing efforts to modernize our platform and enhance the overall experience for our users.
Our SOAP offering comprises two key components: the SOAP proxy client and the web service endpoints.
SOAP Proxy Client - SuperOffice.NetServer.Services: Our SuperOffice.NetServer.Services package, which includes the SOAP proxy client for communication with SuperOffice WCF-based SOAP web services, has played a vital role in our journey thus far.
However, we have observed a significant decline in its usage since the introduction of the RESTful-based proxy client, SuperOffice.WebApi. These two clients offer nearly identical functionality, with SuperOffice.WebApi adopting a RESTful protocol approach. While there are some nuanced differences, detailed information is available in our SuperOffice Docs.
Migration Status: We are pleased to inform you that all SuperOffice applications have either completed their migration away from using the assemblies within the SuperOffice.NetServer.Services package or are currently in the process of doing so. This transition has also involved the move from .NET Framework to .NET Standard 2.0, where we replaced legacy NETFramework 4.8 WCF dependencies with CoreWCF.
Eliminating SOAP Support: As part of our ongoing efforts, we have a strong desire to completely eliminate our SOAP offering when SuperOffice reaches version 12. While we acknowledge that this transition may not be immediate for all partners and integration customers, it represents our vision for the future of our platform where we would like to offer services in alignment with current trends.
Your input and feedback are of great importance to us, and we believe in fostering a collaborative environment where your insights help shape our decisions. We understand that change can be challenging, and we are committed to supporting you throughout this transition.
We encourage you to share your thoughts, concerns, and suggestions with us. Your feedback will be instrumental in ensuring a smooth and effective transition away from SOAP.
Thank you for your continued trust and partnership with SuperOffice. Together, we can embrace this evolution in our technology stack and continue to deliver exceptional solutions to our customers.
Should you have any questions or require further information, please do not hesitate to reach out to us.
Best regards
All Replies (5)
Thanks for the heads-up Tony.
We have been going through the same migration with our own apps/integration, all (except a few customer specific one's) have been migrated to the REST API (or all still on Core).
Since I expect SuperOffice 12 will be atleast a year or 2 away this is good advance notice π This should be made very clear on the documentation in docs.superoffice.com, we regularly point external parties to that (and give the advice to use the REST api, but still).
Regarding the migration status, as far as I know both WebTools and Service using the SOAP API now, is there an expectation/goal to have included all service functionality within the CRM.Web by SuperOffice 12? Or will Service switch to the REST API? Just interested in what the plans are there.
For current apps, we already use only the REST APIs. However, we have many apps that still use SOAP.
We need to coordinate and test this migration of these modules with our common customers.
This will be a nice challenge π
Thanks for the early announcement Tony!
This will cause some challenges but it's very fair and acceptable to take into account for SuperOffice 12.
Will these plans in any way affect the Database Mirroring Service framework which uses only WCF/SOAP today? Is it likely to assume that the changes might affect this service at some of the later stages of the deprication of the SOAP-API?