We have written about Marketing requirements for publishing your app on AppSource in our previous blog post here. Now we would like to introduce our Dynamics Partners about technical requirements for publishing your app on AppSource. If you do not have enough resources in-house, Simplanova offers our services: Add-on migration to AppSource, Add-on Development, Upgrades for Add-ons to Extensions and much more. Contact us and get a free project evaluation.
You can bring two types of offerings to Microsoft AppSource:
- Add-on Apps (that brings your industry expertise to market), Connect Apps (that connect services) and Embed Apps.
- Packaged Consulting services (that bring ready-made packaged engagements to market).
There are several things to keep in mind in when building an Add-on App. The following checklist sums up all the technical requirements that you must meet before submitting an Add-on app for validation. If you do not meet these mandatory requirements, your app will fail validations. We are sharing the information from Microsoft and what our team learned during Directions EMEA 2018.
Prior Publishing Your App to AppSource
- Get the Microsoft Partner Network (MPN) account.
- Register at the Partner Source.
- Get a Microsoft Developer Account (Developer account is required to submit app to AppSource or to any other App a.e. Windows).
- Obtain your Object Range – unique license to:
· get to the Cloud Partner Portal – to submit, validate apps for AppSource;
· register at Microsoft Collaborate – to access Business Central Builds;
· Reserve you Prefix – require to maintain your code to avoid collisions with other developers.
- Azure VM
- Local Deployment
Checklist for Submitting Your App
The following is a checklist of all requirements that you must meet before submitting an extension for validation. If you do not meet these mandatory requirements, your extension will fail validation.
- Data Classification is required for all fields of tables and extensions. All should have data classification for GDPR.
- Develop your extension in Visual Studio Code.
Visual Studio Code and the AL Language extension lets you do the following tasks:
- Create new files for your solution.
- Get assistance with creating the appropriate configuration and setting files.
- Use code snippets that provide templates for coding application objects.
- Get compiler validation while coding Press Ctrl+F5 to publish your changes and see your code running
- The app.json file has mandatory settings that you must include:
- Privacy Statement link is missing or is incorrect;
- Help Link missing;
- Target set on Internal and not the required Extensions;
- ID Range not set to your own Object Range.
In an AL project there are two JSON files; the
app.json file and the
launch.json file. These files are generated automatically when you start a new project. The
app.json file contains information about extension that you are building, such as publisher information and specifies the minimum version of base application objects that the extension is built on. Often the
app.json file is referred to as the manifest. The
launch.json file contains information about the server that the extension launches on.
More settings in the app.json file you can find here.
The following table describes the settings in the
launch.json file. The
launch.json file has two configurations depending on whether the extension is published to a local server or to the cloud.
- Coding of Date must follow a specific format (no longer region specific). Use the format
yyyymmddD. For example,
- Remote services (including all Web services calls) can use either HTTP or HTTPS. However, HTTP calls are only possible by using the HttpRequest AL type. With the API for Dynamics 365 Business Central you have HTTP, JSON, TextBuilder, and XML classes available for accessing services. You can find more information here.
- The .app file must be digitally signed:
- Certification from 3rd party certification authority;
- The steps to follow for signing the app are listed here;
- Examples of acceptable 3rd party providers are GoDaddy, Digicert, Symantec.
- The user scenario document must contain detailed steps for all setup and user validation testing.
- Internal use only. Targeted specifically for validation;
- Not meant for every scenario. Focus on most common usage;
- Include all setup needed for successful testing;
- Be Detailed. Use screenshots;
- Include specific values which are important for success.
- Set the application areas that apply to your controls. Failure to do so will result in the control not appearing in Dynamics 365 Business Central. Make sure that all is set correctly: Page Controls, Usage Category.
- Permission set(s) must be created by your extension and when marked, should give the user all setup and usage abilities. A user must not be required to have SUPER permissions for setup and usage of your extension.
- Include at least one permission set;
- Give users full usage of app functionality;
- Never force user to be SUPER;
- Never restrict a user from using core BC.
- Before submitting for validation, ensure that you can publish/sync/install/uninstall/reinstall your extension. This must be done in a Dynamics 365 Business Central environment.
- Thoroughly test your extension in a Dynamics 365 Business Central environment.
- Do not use OnBeforeCompanyOpen or OnAfterCompanyOpen.
- Include the proper upgrade code allowing your app to successfully upgrade from version to version.
- Pages and code units that are designed to be exposed as Web services must not generate any UI that would cause an exception in the calling code.
- Upgrade code units:
- Use correct upgrade procedures;
- Properly code to handle every situation;
- Test the upgrade with data;
- Cover all upgrade paths (not only v1->v2->v3 but v1->v2, v1-v3 and v2->v3).
- You must include all translations of countries your extension is supporting. The use of xliff is required.
- Decide countries your app will support;
- Translation file required for each language code (FR-CA.xlf, en-CA.xlf);
- Remove.CaptionML properties (CaptionMLproperty is obsolete)
- You are required to prefix or suffix the Name property of your fields. This eliminates collision between apps.
- Prefix/suffix eliminates collision between apps. It is impossible to publish the 2 same apps or 2 tables with same name.
- Register your prefix/suffix by sending the email to firstname.lastname@example.org.
- On all object names you have to use prefix, suffix. Adding fields actions to page/table extensions also requires having suffix.
- Few objects with same name can not be in two separate apps.
- AppSourceCop tool should be used in VS and will help you validate the your prefix/suffix.
- You are required to include a Visual Studio Code test package with your extension. Ensure that you include as must code coverage as you can.
- DataClassification is required for fields of all tables/table extensions. Property must be set to other than ToBeClassified.
- Setup fresh Docker Container.
- Publish, Sync and install the app.
- Run wizards and assisted setups.
- Execute setup and usage scenario.
- Check for permission errors.
- Uninstall and unpublish app.
- Republish and reinstall app.
- Test your upgrade.
Marketing requirements for publishing your app on AppSource we have published in our previous blog post and Technical requirements we have listed above are just the few parts you need to know to make your app live in AppSource. Before publishing it, there are many things to know and learn in the development phase. Simplanova has 6+ years experience delivering successful upgrade and development projects to Dynamics Community (100+ customers worldwide). Become a successor with your project and get a free quote on Add-on Upgrade to Extensions, Dynamics NAV Extension Workshop, Extension /AL Development, Add-on Development, Add-on migration to AppSource.