I would like to export a stock item from an Acumatica instance as a data contract, but without calling an API. I don't want to call an API, because I need to retrieve it from inside an instance, not external to the instance. I think all I really need is a way to call the contract-based code to serialize into JSON, but without using a URL. I guess I could call the API within the same instance, but it seems like it should be easier than that.
0
votes
1 Answers
0
votes
Strictly speaking you want to make API calls. Specifically using the 'contract-based API' without using the 'web services API'. This seems to go against the design goals of the contract-based API.
Consider the following statement: Contract-based APIs are built on an object model that the web services API provides. Source: https://adn.acumatica.com/blog/yes-we-have-an-api-for-that-an-introduction-to-the-acumatica-cloud-erp-apis/
The web service API provides the object model of the contract-based API. Remove the web services API of the equation and the contract based API is missing the object model it is dependent on for object serialization. Practically this means that methods that deal with contract-based serialization will require the web service object model as input parameter.
I believe there would be several technical hurdles preventing instantiation of the web service object model without using the TCP-IP stack. This is mainly because the original design goal of the contract-based API is to be called through web services.
This boils down to Acumatica using different object models for different contexts. Contract-based uses the 'entity' model while customizations use the 'DAC' model. There's also major difference in the querying API. Customizations uses BQL and contract-based have other methods.
There are obvious advantages in having a unified object model. Learning to use only one is easier than having to learn two. Using exclusively JSON is easier than mix and convert XML and JSON. However each model also have their disadvantage. Having different models allows the use of a model better tailored to the task at hand. Common requirements for object models are performance, human readability, memory footprint, ability to be easily machine parsed etc..
That said if all you need is the object model of contract-based API without the querying interface you could approximate it by using BQL and serializing the DAC objects to JSON. Because almost all DAC objects have the C# Serializable attribute it should be much easier to serialize the DAC objects retrieved with BQL than use data-contract API to retrieve and serialize the records without going through TCP-IP stack. It would also go in the same direction of the design goals of the API which is that the contract-based API should be used for access through webservice.
