When another application needs to exchange information with Dynamics GP, the connection must do more than move data. It needs to support the right business process, apply appropriate access, and provide a way to identify failures.
Dynamics GP Service Based Architecture, often shortened to SBA, is one integration method to evaluate. Whether it fits your project depends on the operations available in your environment, your security requirements, and the work needed to maintain it.
Start with the process you want to improve before selecting the technology.
Key Takeaways
- Service Based Architecture supports REST-based integrations with Dynamics GP.
- Confirm that the required operations are available before committing to an approach.
- Include permissions, testing, error handling, and ongoing ownership in the project plan.
What Is Dynamics GP Service Based Architecture?
Microsoft describes Service Based Architecture as a way to expose GP application functionality through REST-based service calls.
Its components include the GP Service, which authenticates incoming requests, and Dexterity services that execute requests through a GP runtime. Microsoft requires SSL configuration for the GP Service.
For a business team, the important question is what the connection needs to accomplish. For a technical team, the next question is whether SBA exposes the operations required to accomplish it.
Do not assume that every GP function, customization, or add-on is available through the service.
When Should You Evaluate SBA?
SBA may deserve consideration when a project requires another application to call available GP functionality through a REST interface.
Before choosing it, define:
- Which application initiates the request.
- Which information needs to move.
- Whether the process reads information, creates records, or changes existing records.
- How quickly the information must be available.
- What should happen when a request fails.
For example, replacing repeated manual entry may involve different requirements from providing information to another application. Document the actual transaction and expected result.
This overview of integration and custom software development can help frame the broader project.
Compare Integration Methods Before Choosing One
SBA is one option within the GP integration toolkit. Ask your GP partner to compare approaches against your requirements.
| Requirement | What to establish |
|---|---|
| Required functionality | Whether the method supports the specific operation |
| Data validation | How business rules and required fields are handled |
| Processing schedule | Whether the connection needs immediate or scheduled processing |
| Volume | How the approach performs with representative workloads |
| Maintenance | Who will support it after updates or application changes |
| Cost | Development, licensing, infrastructure, and ongoing support requirements |
For a defined file-import process, review using Integration Manager to import journal entries into GP. A file-based import and a service-based connection solve different needs; select the approach that fits the work.
Confirm Your Environment and Available Services
Have your technical team document the GP version, installed components, instance, tenant configuration, and relevant customizations.
Microsoft’s installation guidance includes a discovery-service check to verify SBA access. Its example uses a URL in this format:
https://ServerName:PortNumber/GPService/Tenants(DefaultTenant)/help
The server, port, and tenant must match the installation. Reaching the discovery service is an initial verification step, not proof that a complete business transaction will work.
Ask your developer to confirm the available operations, request requirements, and expected responses in the actual environment.
Define Access Before Development
Identify which account the integration will use, what it must access, and who will maintain it.
Document:
- The required GP companies and operations.
- Authentication and credential-management arrangements.
- Appropriate permissions.
- Responsibility for account changes.
- How access will be reviewed and removed when no longer needed.
Review Dynamics GP user types, licensing, and access with your partner. Confirm integration-specific licensing requirements rather than assuming an existing user license covers every connection.
Need Help Selecting a GP Integration Approach?
Bring the applications involved, the information that needs to move, and the manual work you want to replace. LBMC Technology Solutions can discuss your requirements through its integration and software development services.
Test the Business Process, Including Failures
A successful request is only one part of testing. Confirm that the result is correct in GP and that exceptions can be investigated.
Build tests around:
- Valid information: Does the request produce the expected result?
- Missing or invalid information: Is the issue identified clearly?
- Repeated requests: Could a retry create a duplicate?
- Access restrictions: Does the account have appropriate limits?
- Interruptions: What happens if the connection or service becomes unavailable?
- Representative volume: Can the process handle the expected workload?
For financial information, assign responsibility for reconciling results. Confirm that company, account, and reporting values are mapped correctly. This explanation of segments and dimensions in Microsoft Dynamics can help prepare that discussion.
Assign an Owner for the Connection
Before launch, establish who monitors failures, reviews logs, manages credentials, and coordinates changes.
Keep documentation for the data mapping, configuration, test cases, and recovery procedures. Include the connection in testing after GP, infrastructure, or connected applications change.
Also consider how long your organization expects to use the integration. Your Dynamics GP support and migration plan should inform decisions about new development and ongoing maintenance.
Dynamics GP SBA FAQs
Is SBA the same as hosting GP in the cloud?
No. SBA is an integration technology. Hosting concerns where GP runs and how its infrastructure is managed.
Can SBA expose every GP function?
Do not assume so. Your developer must verify the operations available in your installation and whether additional development is required.
Does reaching the discovery service prove the integration works?
No. It verifies an initial part of the setup. Test authentication, permissions, requests, and business results separately.
Should we replace an integration that already works?
Start with its limitations, maintenance needs, and business value. A different technology should address a defined requirement that justifies the change.
Ready to Review Your GP Integration Needs?
Tell us which applications need to connect and where the current process creates delays or repeated entry. We can discuss an approach that fits your environment and longer-term ERP plans.
