This is fourth post in this series, if you wish to see first post, you can access here.
In second post I discussed about, how to create Azure Functions, you can access here.
In previous post I discussed about, how to Integrate Azure Functions in Business Central, you can access here.
In this post we will discuss how to make available QR Image using API by exposing as Web Service.
Let’s cut the theoretical part and coming directly to the solution.
This post is very short and as an answer to query from one of the blog readers, who regularly gives feedback and suggest topic he wish from me. Sometime it is not possible to write post for every query, but I try to pick some which I find interesting. Converting any topic into post is quite time taking, solution can be of 10 mins but presenting same in form of blog takes 2-3 hours, sometimes even more.
Some time appropriate environment is not available where I can put the solution and take screenshots to present as blog.
Since this topic is part of current series, I am writing posts on, so I was able to easily pick this topic.
Requirement is to add capability to get QR Image we generated in our previous posts using Web Service/ API/ OData/ JSON Base64Text.
To get this working we will first create a Codeunit with appropriate methods and expose it as Web Service.
Step – 1.
Create Codeunit & Add below method.
Step – 2
Publish above Codeunit as Web Service.
Step – 3
Copy SOAP URL
Convert to ODataV4 URL by making necessary modification as below:
Similarly, your $metadata URL will be:
Run the metadata URL in browser:
Search for your function created above, you should get definition as below:
<Parameter Name=”qRSetId” Type=”Edm.Int32″/>
Let’s test the above URL for function using Postman to see the result:
Authorization: Basic Auth
Password: xjAtAtTaFhgXkgR4M5WoHapotvJNmqJ5//XBYK2v5s4= (Web Service Access Key)
JSON Parameter to Function: (Body raw:JSON)
“qRSetId” : “6”
Copy the Value and use any base64 – image converter tool, search on Google
You will get your QR Image:
Don’t try any URL or Passwords in this post as same is modified, and in images covered to hide actual url & passwords.
Hope you enjoyed learning from this post.
That’s all for this post, but visit again to learn from upcoming posts in this series, will post soon.
See you again in next post, till then keep exploring, learning and sharing with others.
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.