The xAssets API
The xAssets API gives programmatic access to all functions making it possible to build powerful connected applications
either to complement an existing implementation or to create an entirely new asset-centric application.
Using the API you can
- Integrate to any system or web service includes ERP, SAAS, PAAS, legacy and cloud systems
- Recognize, cleanse, deduplicate and import complex data structures into the xAssets database
- Import and export data to any format including CSV, Excel and PDF
- Build workflows
- Write custom network discovery tools
- Build customized Single Sign On solutions
Building API Functions
Most applications which offer an API require customers to do programming work in a language such as C# or Visual Basic.
While this is supported, xAssets offers a better solution where your API needs can be met from within the product
without needing to build separate applications or compile code.
The xAssets transformation engine can be used to trigger custom API actions including:
- Access data from any web service, file, database or local application
- Manipulate data in any way, using program code, Sql, or built-in data processing commands
- Apply data recognition and cleaning rules of any complexity
- Run any task before or after a record is saved
- Send data from any data source to any data destination, including the database behind your xAssets instance
- Run reports into PDF files and email them as a scheduled batch process
- Automate server-side workflow processes
- Automate discovery processes within your network
The transformation engine supports it's own language called AMSX, which has full access to all API functions and full data model access.
All functionality and programs are stored within the database so the entire customer's functionality and data are stored together and
moveable as a single file unit.
Which API Architecture is best ?
Almost all API accesses are optimally situated in the AMSX language, there is rarely any benefit to coding API access in separate applications which
have to be hosted on different computers. However customers can choose from any of the following architectures:
- AMSX to embed API functionality within transformations
- C# or VB SOAP calls can be used to retrieve, manipulate and save data, and can run transformations either in-thread or as a batch job
- SOAP calls can also be embedded in other languages
- Restful API calls (i.e. simple URLs with a bearer header token) can be used to pull data from xAssets in any language
- XCS (xAssets Client Scripting Language) can embed API calls and transformation calls within a browser single page application
Often, when a process must be triggered from an external application, the best architecture is to simply call a transformation from that application with one line of code,
and then embed the functionality within the transformation itself.
xAssets engineers typically write and maintain API accesses as part of each customer's implementation project and support subscription.
This means customers gain the flexibility of a deeply configurable and connected solution without needing in-house programming expertise.
This also means that you can achieve your goals "on demand" as your requirements evolve.
For customers requiring programmatic access, a working app is provided with samples for authorization and the most common API calls.