{"id":1478,"date":"2025-12-15T13:52:42","date_gmt":"2025-12-15T13:52:42","guid":{"rendered":"https:\/\/fredborg.org\/?p=1478"},"modified":"2026-01-07T10:30:24","modified_gmt":"2026-01-07T10:30:24","slug":"episode-4-building-the-interface-api-pages-permissions","status":"publish","type":"post","link":"https:\/\/fredborg.org\/?p=1478","title":{"rendered":"Episode 4: Building the Interface (API Pages & Permissions)"},"content":{"rendered":"\n

In the previous episodes, we established our “Agentic” workflow and built the foundation of our Business Central integration: the Staging Tables.<\/p>\n\n\n\n

Now, we need to open the door so the outside world can actually talk to us.<\/p>\n\n\n\n

In this episode, we use Roo Code to generate the API Pages<\/strong>, fix a common real-world error involving entitlements, and finally verify our connection using postman.<\/p>\n\n\n\n

1. Moving Files & Updating the Spec<\/h3>\n\n\n\n

Before we started coding, I noticed a small housekeeping issue: the AI had placed our staging tables in the Common<\/code> folder instead of Source<\/code>. 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.<\/p>\n\n\n\n

We then updated the implementation.md<\/code> plan to focus on Phase 2 (UI) and Phase 3 (API Layer)<\/strong>.<\/p>\n\n\n\n

2. Generating the Code (And Fixing Small “Oopsies”)<\/h3>\n\n\n\n

I instructed the Orchestrator to implement Phase 2. It successfully created the List Pages and Card Pages for our staging tables.<\/p>\n\n\n\n

However, it made a classic AI mistake: it used hashtags in the Application Area (e.g., ApplicationArea = #All<\/code>). In AL development, that’s a syntax error.<\/p>\n\n\n\n

\n

Could I have done a Find & Replace? Yes. But the point of this series is to push the AI.<\/em><\/p>\n<\/blockquote>\n\n\n\n

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<\/strong> in my initial rules, so I instructed the agent to wrap all objects in a MyCompany.WebShop<\/code> namespace to keep things clean<\/p>\n\n\n\n

3. The “Missing Entitlement” Error<\/h3>\n\n\n\n

This was the most critical part of the episode. When I tried to deploy the app, I got a compilation error regarding permissions.<\/p>\n\n\n\n

The AI had generated the objects, but it hadn’t updated the permission sets to allow access to them.<\/p>\n\n\n\n

I asked the agent to generate a new permission set, WebShop<\/code>, with access to the new Staging Header and Line tables. We then registered this permission set in the app.json<\/code> (or Entra ID registration) to ensure the API user actually has the right to read and write data<\/p>\n\n\n\n

4. Refining the API Pages<\/h3>\n\n\n\n

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.<\/strong><\/p>\n\n\n\n

I instructed the agent to:<\/p>\n\n\n\n

    \n
  1. Remove the actions from the API page.<\/li>\n\n\n\n
  2. Add a SubPage<\/code> part for the lines, so we can POST a header and lines in a single call (using deep inserts).<\/li>\n<\/ol>\n\n\n\n

    5. Testing with Postman<\/h3>\n\n\n\n

    With the code deployed, it was time to test. I switched to Postman.<\/p>\n\n\n\n

    I set up a GET request to our new endpoint: GET ...\/api\/myCompany\/webShop\/v2.0\/companies(...)\/webOrders<\/code><\/p>\n\n\n\n

    The Result:<\/strong> 200 OK<\/code>.<\/p>\n\n\n\n

    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 <\/p>\n\n\n\n

    \n