Custom web service in D365FO - Part-II

In Part 1, we covered the foundational elements of creating custom services in Dynamics 365 Finance and Operations (D365FO), including the architecture, request/response contracts, and service class. In this second part, we’ll explore how to implement business logic, test your service, and handle errors effectively to ensure your service is robust and production ready. Its important you take a look to my previous post as I will carry on example from that post.

 Custom web service in D365FO - Part-I

Implementing Business Logic

Once your service class is set up, the next step is to implement meaningful business logic. This could involve querying tables, performing validations, or updating records. Here's an enhanced version of the processMsg() method with actual logic:

Testing the Service

Once deployed, you can test your service using tools like Postman or SoapUI. Here's how to do it with Postman:

1. Set the URL:

https://<your-environment>.cloudax.dynamics.com/api/services/TheAxaptaInterface/TheAxaptaService/processMsg

1. Set Headers:
• Content-Type: application/json
• Authorization: Bearer token (use OAuth 2.0)
2. Request Body (JSON):
3. Send Request and inspect the response.

Error Handling and Logging

Robust error handling is essential for production-grade services. Here are some best practices:

• Use try-catch blocks to handle both X++ and CLR exceptions.
• Log errors using the EventLog or custom logging frameworks.
• Return meaningful messages in the response contract to help consumers understand what went wrong.
• Avoid exposing sensitive data in debug messages.

Example of logging:

EventLog::add(EventLogCategory::Application, EventLogLevel::Error, "CustomServiceError", response.parmDebugMessage());