In our previous post we saw basics of API in Navision. Let’s explore further.
If you missed the earlier post you can find here API – Business Central Part-1
Continuing from where we left in previous post.
Someone asked me why we require API when we have web service in place and can achieve same OData either query or filter in same fashion.
So what I am going to explain below will answer to that query.
The API will generate a REST service which returns OData. The API is not the same as the OData web services that we discussed in our earlier post.
There we created an OData web service based on a card page. If there were fields that need to be displayed on a card in the client application but you do not want those fields to expose in the OData web service, you will have to create a second card page to solve this problem. In this case, we create a separate page for our API and only for the API. This page cannot be requested in the client application. It’s also much better concept to separate them from the regular pages.
Also we can apply templates for default value of field, which we will discuss later in below post.
Let’s start with creating our own API.
Each resource is uniquely identified through an ID. As discussed in our earlier post. So let’s start with this, I will start with my earlier created Table LoadoutPoint and add one field ID.
Any new entry in my table will have a unique ID for Loadout Point, so I have added code in OnInsert trigger of the table.
To create an API, you should create a page of type API, instead of a card page or list page.
Use tpage, Page for type API snippet for page structure. You get all the bare minimum properties to be added for API Page.
Then you have to define which fields you would like to include.
Some important rules to be followed for API Pages:
- Fields should be named in the APIs supported format, Any Captions cannot have spaces and special characters. Only AlphaNumeric values permitted.
- When you insert an entity through API endpoint, Business Central don’t run OnInsert trigger on the table.
- And we have assigned the ID for the new record there. So Add Insert(true) for OnInsert Trigger.
- Add business logic to Modify trigger. As external user can change values through API, even the value of the primary key field.
- Add Delete(true) for On Delete trigger. The reason same as above.
So let’s add these 3 trigger in our page too.
Ok so now we have modified Table and Created new API page, now it’s time to publish our app/extension.
Use command palette to publish your app.
Now it’s time to test, let’s access our API page from client and do setup for same.
Search for API Setup Page in the client.
You can define and assign your Template from Template Code field, check with available same Templates how to do it.
Also the conditions when this Template should apply as discussed in earlier post also.
Now let’s access the API from outside the Navision/ Business Central.
I will use Postman to test this.
To get the list of 44 standard APIs.
To get the list of custom APIs.
Hope you remember when we created API page we assigned few Properties like
APIPublisher = ksdconsultancy, APIGroup = app1, APIVersion = v1.0.
Now we will use those values to access my custom APIs.
See the url those are included after /api/
All information is available in JSON format and further can be confirmed that there are 1000 records. Thus, the number of records integrated here depends on the Max Page Size parameter setup in Navision Server.
What else you can do with APIs:
- Get to fetch or List
- Post to insert records
- Patch to modify records
- Delete to Delete records
- And so on.
- You can extend existing API Pages too, I have yet not tried.
That we may discuss in some other post. Not to complicate this topic more for now I conclude this post here.
Will come up with more details in my upcoming posts, till then keep exploring, learning and take good care of yourself.
You must be logged in to post a comment.