In the previous episodes, we established our “Agentic” workflow and built the foundation of our Business Central integration: the Staging Tables.
Now, we need to open the door so the outside world can actually talk to us.
In this episode, we use Roo Code to generate the API Pages, fix a common real-world error involving entitlements, and finally verify our connection using postman.
1. Moving Files & Updating the Spec
Before we started coding, I noticed a small housekeeping issue: the AI had placed our staging tables in the Common folder instead of Source. I moved them manually. This is a good reminder that while AI is powerful, you still need to be the “Architect” of your own project structure.
We then updated the implementation.md plan to focus on Phase 2 (UI) and Phase 3 (API Layer).
2. Generating the Code (And Fixing Small “Oopsies”)
I instructed the Orchestrator to implement Phase 2. It successfully created the List Pages and Card Pages for our staging tables.
However, it made a classic AI mistake: it used hashtags in the Application Area (e.g., ApplicationArea = #All). In AL development, that’s a syntax error.
Could I have done a Find & Replace? Yes. But the point of this series is to push the AI.
I told the agent to fix the Application Area and remove the hashtags. It did so immediately. I also realized I hadn’t enforced Namespaces in my initial rules, so I instructed the agent to wrap all objects in a MyCompany.WebShop namespace to keep things clean
3. The “Missing Entitlement” Error
This was the most critical part of the episode. When I tried to deploy the app, I got a compilation error regarding permissions.
The AI had generated the objects, but it hadn’t updated the permission sets to allow access to them.
I asked the agent to generate a new permission set, WebShop, with access to the new Staging Header and Line tables. We then registered this permission set in the app.json (or Entra ID registration) to ensure the API user actually has the right to read and write data
4. Refining the API Pages
When generating the API pages, the agent initially included an “Action” on the API page. As experienced BC developers know, API pages cannot have actions.
I instructed the agent to:
- Remove the actions from the API page.
- Add a
SubPagepart for the lines, so we can POST a header and lines in a single call (using deep inserts).
5. Testing with Postman
With the code deployed, it was time to test. I switched to Postman.
I set up a GET request to our new endpoint: GET .../api/myCompany/webShop/v2.0/companies(...)/webOrders
The Result: 200 OK.
We successfully authenticated and retrieved an empty list (since we haven’t posted data yet). This confirms that our API pages are published, our namespace is correct, and our permissions are active