Today I want to speak with you about new Contract-Based Web Services API that you can use in Acumatica 5.3 version.
The main differences between previous Screen-Based API and new AP:
- Previously you had to use names of fields and actions right from Acumatica UI. And if we rename or move field your code will stop working. Now new API has an intermediate layer between Acumatica UI and the integration code, so can be sure that most of minor changes in Acumatica code will not break existing integration.
- New API is easier to use. You need less lines to complete the same task. Also it is more intuitive, so it will easier for you to write a code.
- The current API just isn’t well adapted to REST. But now you can feel very strong industry trend toward to REST.
So now you have intermediate layer that we call “Endpoint”, We will keep and evolve default (build-in) endpoint that can be used for most of common task, but if you need more complex or specific logic than you have 2 options:
- You can configure new one in Acumatica user interface. (Fast and flexible, but requires support).
- Ask us to add new logic to default endpoint. (Long, but much easier to use and support)
Endpoint contains screens, linked/detail contains, field and actions. All these items has names that will be expanded through web services. On the other side all these items connected with Acumatica user interface elements.
When everything required is mapped you can start to use web service.
In this example i will show you how to use Stock Items thought API. For my task it is enough to use default endpoint, so i will use it.
If you click on “View Endpoint Service” you will see web services definition with all possible methods. The main thing that you need at this point of time is URL of web service.
You will use this url in Visual Studio (Or other environment) to import web service definition.
And the last preparation step – do not forget to enable cookies and increase request limit.
Now we can start development.
Here you can find code example that will show you some basic scenarios of using contract-based web services. You can copy it to your project in Visual Studio and try to play around
The classic web services API is not going anywhere and will remain supported. But it is better to built all new projects on the new contract-based web services API – sometimes next year it will become mandatory for solution certification.
Existing code can be migrated gradually; you can mix both technologies in the same product (You can share session cookies to avoid needing multiple logins).
Have a nice integration!