08 March 2020

Object types is case sensitive in TenantWebServiceCollection

Last week while I was working on an integration project, I wanted to call a Business Central function from Azure Logic Apps. I had few options with APIs but I went ahead with creating a CodeUnit with a function and expose it as a web service.

Rather than exposing the CodeUnit by manually inserting an entry in the Web Service table, I used the new TenantWebServiceCollection option. I created below XML under my extension repo and published the extension with the expectation to see a ManageBCWSCall web service on the published web service page.
 <?xml version="1.0" encoding="utf-8"?>  
 <ExportedData>  
   <TenantWebServiceCollection>  
     <TenantWebService>  
       <ObjectType>Codeunit</ObjectType>  
       <ObjectID>50000</ObjectID>  
       <ServiceName>ManageBCWSCall</ServiceName>  
       <Published>true</Published>  
     </TenantWebService>  
   </TenantWebServiceCollection>  
 </ExportedData>  

Things didn't go well with me on that day and adding more to that I could not find my published Web Service. 

After a few minutes, my colleague (Can Ates) suggests that object type might be case sensitive. To try out his theory we change the object type to "CodeUnit" and published the extension. This time it worked. 

 <?xml version="1.0" encoding="utf-8"?>  
 <ExportedData>  
   <TenantWebServiceCollection>  
     <TenantWebService>  
       <ObjectType>CodeUnit</ObjectType>  
       <ObjectID>50000</ObjectID>  
       <ServiceName>ManageBCAPICall</ServiceName>  
       <Published>true</Published>  
     </TenantWebService>  
   </TenantWebServiceCollection>  
 </ExportedData>  


Thank you Can Ates. 

Keep in mind that object type in the TenantWebServiceCollection is case sensitive. 
Please provide your feedback with a comment.
Thank you and Regards,
Tharanga Chandrasekara
Read more »

01 March 2020

Obsoleting Microsoft Dynamics 365 Business Central Events

If you are working on the extension development, then I'm sure that you already have published and subscribed to many events. There are some rules that you should strictly follow around events if your extension is eventually be used by another partner to build their solution on top of yours. 

Business Central has two types of events it's vital to decide which type of event you want to create. 

Business Events: A business event is a custom event that is raised by the AL code. It defines a formal contract that carries an implicit promise not to change in future releases. It is the expectation that business events are published by solution ISVs, including Microsoft.
Integration Event: An integration event is also a custom event that is raised by AL code, like a business event, except that it does not carry the same promise of not changing, nor does it have the restriction not to expose implementation details. The main purpose of integration events is to enable the integration of other solutions with Dynamics 365 Business Central without having to perform traditional code modifications.
In simple words, a Business Event is a promise made to the outer world that it will not be changed. 

If you have defined below two events in an earlier release of your extension and after a few releases you realize you must change the definition of the event or completely want to remove the event. 


Even though you have made a promise to the outer world, still you have to change the defined business event. 

If you just went ahead and change the event signature or remove the event and deploy the extensions, it will definitely break the other dependent extensions that have subscriber implementation to the event you just changed. 

See the example below, Subscriber in the extension B cannot find the "MyBusinessEvent" event in the extension A anymore. This will break extension B and force partner to rework on their extension B. 

This will definitely question your extension credibility and other partners might look for another more credible extension to use. 

Then don't you have an option to change this event? The simple answer is NO. 
You should never change the current event signature or remove the published events from your extension. 

BUT if you really want to change it then you should select a path that will not cause issues immediately to the other dependant extensions. Microsoft has introduced a way to handle these type of changes. 

You can obsolete your current business event and create a new business event with a new signature (MyBusinessEvent01)

Extension B will get a warning like below and this gives enough time for the developer of the Extension B to switch the subscriber to new implementation. 

You can give enough time for the other partners and also update your release documents with the breaking changes before you permanently remove the initial implementation of the event. 

Please provide your feedback with a comment. 
Thank you and Regards,
Tharanga Chandrasekara
Read more »

Microsoft Dynamics 365 Business Central Wave 1 2020: Release note explained.

A few weeks ago Microsoft published the 2020 release wave 1 plan for Dynamics 365 and Microsoft Power Platform document. This document contains details about many new interesting functionalities and features. Below are some of the features that got my attention.

Look up events and insert event subscribers in code
One challenge most developers face each day is to find the correct event and generate an event subscriber signature. With this newly added feature, develoepr can easily search through the available event list and generate subscriber signature and insert it into code context. 
Use the new Shift+Alt+E shortcut in the AL code editor to invoke a list of all events. You can use type ahead to dynamically search and filter the event list, and when pressing return to select an event entry, an event subscriber for the event will be inserted at the cursor position in the active AL code editor window. 
Multiple variable declarations of the same type in the same line
I was looking forward to this from the day I saw it during NAVTechDays. No more lengthy list of variable declaration.  
Declare multiple variables of the same type in the same line, using a comma to separate variable names. For example, "foo, bar : Integer;
Ability to refactor a field from a table to a table extension 
This would be good news for most of the On-premise customers who are looking forward to migrating to SaaS. With this new feature, the developer can move the custom fields to a table extension without writing any upgrade code. However, think very well before creating table extensions as it will have an effect on application performance. 
Using Sync-NAVApp, a developer can move a field from a table to a table extension without the need to write upgrade code
API for continuous delivery of the AppSource apps via Azure DevOps services
This will allows partners to manage their apps and orchestrate the steps of the app release. This will not be available for all partners immediately. 
The partners will use a new API (fixed app management endpoint, of FAME) and Azure DevOps services to manage their apps and orchestrate the steps of the release (release pipeline). Once a partner app has been tested in a Docker container and has passed automated AppSource validation checks, the production-ready app will be submitted for the AppSource automatic and additional manual validation via the Microsoft Partner Center portal as usual. When the app is approved, the ISV will proceed with a phased rollout of the app to all of its customers, using the previous version of the ISV app, across multiple countries. New versions of the partner apps will be made available to the customers to upgrade to on the Extension Management page so that customers can install or upgrade to those when they see fit. 
Business Central integration with Common Data Service
This was first demonstrated during NAV TechDays and I was very much looking forward to this. The new feature will allow to connect to CDS and associate a Business Central company with the CDS business unit. Not sure how this is been added to the product but hopefully it will not be similar to the current CRM connector which runs based on Job queues and has very limited capabilities. 
When developing extensions that integrate with Common Data Service, Business Central 2020 release wave 1 will bring extensibility capabilities, where Common Data Service tables and Common Data Service table extensions can be created. This will allow for any custom attribute to be synchronized
Read scale-out
No more system performance issue when a selected API, Report or Web Service runs to read the data from Business Central. Selected API, Report or Web Service can read the data from a replica of the database and this will helps to improve active user experience. This means there will be no impact on the primary database while pulling large sets of data. 
Business Central artifacts (Reports, API Pages, and Queries) now can get access to a read-only replica of the database. The Page, Report and Query objects have a new property called “DataAccessIntent” that can take values ReadOnly or ReadWrite. This property works as a hint for the server, which will connect to the secondary replica if possible. When a workload is executed against the replica, insert/delete/modify operations are not possible, so a new validation is introduced for ReadOnly objects. Any of these operations will throw an exception at runtime (new compile-time validation will be added in the future)
AL interfaces
Waldo and Tobias already wrote about this new feature soon after the NAV TechDays. I would suggest you read those above mention blog posts for more information. This is a one-step forwards towards the OOP.
Use the new interface object to declare an interface name along with its methods, and apply the implements keyword along with the interface names on objects that implement the interface methods. The interface object itself does not contain any code, only signatures, and cannot itself be called from code, but must be implemented by other objects. The compiler checks to ensure implementations adhere to assigned interfaces. A new QuickFix CodeAction can be used to insert interface stubs, if the compiler errors on one or more interface implementations are missing.

There are many more new functionalities available and read my next blog posts to know how to get access to the new Business Central version 16 environment. 

Please provide your feedback with a comment. 
Thank you and Regards,
Tharanga Chandrasekara
Read more »

Notes from Directions EMEA 2019


Below are some notes I took during Directions EMEA 2019. A bit late to publish but didn't want to just delete them. 

Treat extensions as products.
    • Which means releasing them to customers periodically.
    • Allow proper testing with proper test cases (Preferably automated testing).
    • Try to run all the customers on the same version.
    • Proper code freeze before testing starts. 
    • Configs should be in installation codeunits, upgrade codeunits or in Config packages
      • It can be automated during the installation
Customer extensions
    • The release should be periodic (Can make an exception if the fix is urgent).
    • Data changes should be in upgrade codeunits.
Dependency
    • Should NEVER merge extensions together just because to avoid dependency.
    • If the dependency is troubling the deployment then try to restructure the extension.
CI/CD
  • CI/CD is a must with extensions as it makes life easy for the developers and also for consultants.
  • If you are not an expert on DevOps, then do not try to reinvent the wheel.
    • Try to implement a simple pipeline with available extensions and add-ons.
    • Once your company is compatible with the CI/CD and has a better understanding then invest in finding a solution that is perfect for your organization.
Number of objects
  • The number of objects in an extension should be less than 100 (not a rule, but if the objects exceed 100 then it is a good idea to rethink the design).
  • If the object count is going more than 100 that means (in most cases) this extension can be split into different modules.
  • Once the extension is split into different modules, it is easy to manage and implement.
Connectors
  • New Logic Apps, Flow and PowerBI connectors allow selecting the environment.
Power Apps
  • To make the user’s life easy, try to use PowerApps for data entering.
Telemetry
  • Create dashboards for Extensions using available new telemetry APIs.
  • This allows partners to monitor the extensions and take actions before it ran into issues.
Try to go global not only local
  • BC is an online platform so partners get the opportunity to go global.
  • Whoever starts first wins.
  • Get your apps to the market and make your mark.
Please provide your feedback with a comment. 
Thank you and Regards,
Tharanga Chandrasekara
Read more »

AL: Dependencies to System and Base Application

Another draft post that I forgot to publish. 

From version 15 onwards, Microsoft decided to split the entire application into 2 apps. 

  1. System Application
  2. Base Application

From going forward if you are developing an app on top of the Business Central, it must have a dependency on System Application and Base Application. 

This does not mean you can completely get away from specifying the "application" and "platform" versions in the app.json file. You still have to keep the "platform" version in the app.json. 


Please provide your feedback with a comment. 
Thank you and Regards,
Tharanga Chandrasekara
Read more »

AL: Action Property must have a value

This blog post was sitting on my draft folder for the past few months and finally got time to hit the publish button. 

AL compiler getting smarter day by day. In previous versions even if we declare an action and never implement the OnAction trigger or assign the RunObject property it never gave a warning or make any complaints. 

However, with the new AL compiler, it identifies the missing implementation and provides a warning to the developer. 


Please provide your feedback with a comment. 
Thank you and Regards,
Tharanga Chandrasekara
Read more »