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.
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:
- Set
the URL:
https://<your-environment>.cloudax.dynamics.com/api/services/TheAxaptaInterface/TheAxaptaService/processMsg
- Set
Headers:
- Content-Type: application/json
- Authorization:
Bearer token (use OAuth 2.0)
- Request
Body (JSON):
- 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());
