Move your code to events with Dynamics 365 Business Central

Hello. And welcome, my name, is Gary winter, in, this video I will show you how to move your code to events, to arrive at an event based, architecture. In Microsoft. Dynamics 365. Business, central. Let. Us have a look at the agenda of this video we. Will first briefly look at the scope of this video I will. Then give you an introduction, to events. After. Which we are prepared, to look at practical examples, of how to move code out of by cross off base app standard, objects, and into, our own objects. This. Video is about strategic. Decisions, on moving, an existing, traditional, code base to an event based architecture. And first. And foremost about how to prepare for that in CIL. It. Is about the transformation. Process and not, yet about working in Visual Studio code, al. If. You want to learn more about developing. Extensions, in Visual Studio code, al please, have a look at other videos in the series which. Are about working, in vs code handling. Events in vs code al and implementing. Table, and page, extension, objects, in vs code al. In. This, video you, will learn how to lay the groundwork, for that, if. Your goal is to transform, your existing, traditional, code base the. First step is get your ciaela, code ready for business central extensions. You. Do so by minimizing your, impact, on the base app which. Will also boost the update ability and lower, coupling, for your on-prem code base based on Microsoft, Dynamics NAV, 2018. By. The way I would, recommend, to watch our video on the structured development, methodology, before, jumping into event based architecture. If you, have not already done so. The. Goal is to move all of your code which, is inside base app objects. Into, objects, of your own by, leveraging events. If there, remains code which cannot be moved easily you. Will need to develop a strategy for refactoring. That code. Let. Us first discuss why, we even care, about events, in the first place. Events. Allow us to react to what goes on inside, the Microsoft, base app and to, enhance that business logic, an. Event based software, architecture, has a zero, footprint, in the base app it, does improves, the update ability, of our own code tremendously. And it. Decreases the impact of changes, in the base app. So. An event based architecture. Is a good thing as such, but. With Microsoft, Dynamics 365, business, central the. Main point, is that it enforces. Event, based coding for Microsoft app source an. Extension. That gets published on app stores must, have no code customization. In the base app. Vertical. And horizontal add-on. Apps or connect apps do not allow any direct, changes, in base app objects. Visual, Studio code al extensions. Can, enhance, base app behavior, only, by, reacting. To, events. So. Which events, can we react to in the first place, there. Is a comprehensive. Typology. Of events, and a, more simplified, one let. Us have a look at the official Microsoft differentiation. Between event, types first. There. Are system and application, events. System. Events are split into global, events and trigger events. Global. Events are events which are automatically, raised in code unit 1 such. As on before, company open or on, after company opening. Trigger. Events, are split into table, and page, trigger events a, system. Event of a table, is automatically. Raised whenever, a database, transaction is, triggered and whenever, a table, field is validated. All. Of these trigger events, come with an on before, and an, on after, event that you can subscribe to, to. Give you an example, there. Is an on before, insert, and an on after insert event on table, level this, is true for modify, delete and rename of Asians as well on. Field. Level, there, is an on before validate, and an on after validate event for each physical field in the table at. Field. Trigger level the, difference, is that the on before, validate, event is called before any code, in the respective. Validation, trigger of the Microsoft, Bayes app and, the. On after, validate, is. Called. After. This base app code has been executed. If. There is no code in the field validation trigger, of the Microsoft, base app there, is no difference if.

There Is code you, need to decide whether your code should come before or, after. The base app code has been executed. To. Be perfectly clear that is. Your only alternative. You. Cannot execute code, in between base app code and you. Can also not execute, code instead. Of base, app code there, is no override. Mechanism. When. We look at crude triggers, like on insert, or modify, on delete, and on rename, there. Is a subtle, but important. Difference the. On before insert trigger is executed, before the base app code in the on insert trigger and the on after insert sugar is executed, afterwards, but. What is very important. To take into account is, that the on after, insert, trigger gets fired after, the, record has already been written to the database. So. If you want to use the honor after insert trigger to modify, the record, that has just been inserted, you, need to read it again before, doing so in. Any. Way it, is not good practice to be performing, any modifications. On the record itself after, it has been written to the database the, on after insert on after modifying, after delete and on after rename, triggers, are designed, to give you the chance to perform any action, in your regard to associated. Tables. Page. Triggers, work in much the same way giving, you access to system, events on pages like an open page or, two page field validation events. Most. Useful, is that they also give you access to actions. Differ and on pages. Application. Events, follow a different concept, than system events. Application. Events need coding, in the Microsoft, base app to be accessible. Since. You cannot put any code inside the Microsoft, base app you. Can only react to application, events that Microsoft, has provided itself, an. Application. Event is designed to enhance business, logic rather. Than to just react, to changes. On field and table level. The. Microsoft, base app publishes. An event inside a base app object, and raises. It at the right point in its business logic the. Developer, is able to subscribe, to that event and enhance.

The, Business logic, there. Are two types of application, events, integration. Events and business. Events to. Demystify. Program. Behavior is exactly the, same regardless. Of whether an application, event, is published, as an integration, or a, business, event, the. Difference is more of a philosophical. Kind an, integration. Event may change in between versions. When. However, you publish, a business. Event you, indicate, that you establish, a formal contract, and promise. Not to change, that event in future, releases. As. I said before you, can greatly, simplify, the event, typology which may give developers a better initial access to the concept, you. Can think of only two basically, different types of events system. Or trigger events, are events, which are raised automatically. Because, a field has been validated or, a database. Operation, has been executed, you. Will find no code in the application for, system events they just get fired, an. Application. Event on the other hand is any, event, which is published, and raised through, code. The. Subscription, mechanism, for both kinds of events is the same on. The. Right hand side of the screen you see a few examples for system, or trigger events, on the one hand and, application. Events on the other the. Examples, for, application, events come from code unit 80. Please. Be aware that, while, the on validate trigger. Is a standard. System event, there. Is no, event, which reacts, to on lookup neither. In tables, nor. In pages. This. Overview summarizes. All table, trigger events, you. See how every event has an on before, and then on after component. They. Are listed in alphabetical order. You. Can also see which parameters, are passed to the subscribing, functions. The. On before validate, event and the owner after validate, event are of special interest if you, subscribe to a validate, event you, will need to specify which, field validation, you actually want to subscribe to. If. Any integration. Of business events were defined for this table which, happens, to be the currency table, they, would also show up in this listing. This. Is the equivalent, listing for page trigger events, the. On before action event and the on after, action event will require you to specify the action, that you want to subscribe to. The. Link on the bottom of the screen leads, to a complete, explanation, about the concept, and implementation. Of events. Let. Us jump into a practical, example of how to shift code from an object in the Microsoft, base app to, an object, in your number range by, leveraging, events, as. You. Can see in this example there. Is code customization. In table, 18 in, the customer table at. The end of the unanswered, trigger a method. Is called which obviously, starts, an onboarding, process, for the new customer. This. Calls a function in the customer, table which is a method declaration, this. Method, declaration. Points to a code unit in your own number range which actually, implements. The function. Again. If you're not familiar with this architecture you, may want to have a look at the video on structure development methodology. In. An event based architecture. This code cannot, remain as it is both. Our code, customized function, on the customer, table and it's. Referenced, in the on insert trigger need to be mood moved out of the base app table, 18. To. Move the reference, in the on insert regard, of the base app table we. Create a so called handler, code unit for the customer table in this. Code unit, in our number range we. Create a function which subscribes. To the on after, insert rigor of the customer, table, this. Function then calls the method start, onboarding, process. Please. Watch out for a few things. First. Of all there, is the parameter, run trigger this. Is passed from the system event to the subscriber, if. You subscribe to assist of table event the, subscription, is always. Executed. Regardless. Of, whether the validation.

Or Data operation, has been invoked with a parameter true, or, false, so. The ownafter inserts system, event will be fired, even. If the customer, has been inserted with custard, insert, false. The. Boolean parameter run, trigger shows, you whether true or the default Falls have been used in calling the system trigger and allows. You to react respectively. Likewise. You should always think about what you want to do if the record is just a temporary record, there. Are a lot of methods that you do not want to execute on a temporary record, this. Is not only true in the specific, context, but, you should make it an integral part of your considerations. How, you want to react, if run trigger is false and its temporary, is true. You. Also see in this example that, the event handler, code unit catches, the event but. There is no real business logic coded, here all, the, subscriber, does is check whether it wants to react, to the event and then. Call, the appropriate method. The. Declaration, of the method was formally, done on the table itself this. Also needs to be moved out of the Microsoft, based app object, so, instead of declaring the method on its original class we, create, a customer. Class code, unit which contains all of its additional, methods, these. Will then point to the respective, method code unit for execution, in much the same way they used to do from the customer table before. So. Originally. We, had these three elements one. A method. Declaration, on the customer, table within the base app to. A method. Code unit which implements. The method, in our number. H3. An additional. Line of code in the on insert trigger of the customer, table within the base app. What. We end up with after. Moving the code to an event based approach, is the following. One. An event. Handler code unit, for the customer, table in our number range, to. A, customer. Class code unit for the customer, table in our number range. 3. A method. Declaration, in the customer, class code unit. For. A method. Code unit which implements. The method in our number range this, is the only part that remains, unchanged. 5, an. Event subscriber, which, catches the on after insert event of the customer, table and calls, the method declaration. In the customer class code unit. We. See that the business, logic as such the. Method, code units start onboarding, process, remains. Entirely. Unchanged. It's. Just the architecture. Of what gets called from where that, changes, around it. Now. Let, us look at this example in a step by step approach. We. Have based this example on the assumption, that you are coding, according, to the structure development methodology, in, that case start. Onboarding, processes a function, on the customer, table which, declares a method, that points to a code unit of the same name. The. General, architecture works. In the exact, same way though if your code looks different. First. Of all you, need a code unit called customer, class in. Which you transfer, all of your additional methods. For the customer table you. Either create this class code unit or you, add the method to it who have already created it before. You. Need one class code you need for every table which you have developed additional methods, for so. There may be a customer, class code unit a vendor, class code unit an item, class code unit and so on add. A suffix. To the code unit name which, refers, to your extension. In order, to make the name unique, because. Other extensions. May have added their own customer.

Class Code unit as well in. Our, example, we have chosen the, acronym my, see. You. Then need a code unit called customer, event handler, which. Handles all of the events of the customer, table that you need to subscribe to you. Either create this event handler code unit or you add a subscription, to another event if you have already created it before. Again. There. Should be one event, handler, code unit, for every, object the, triggers, of which you need to subscribe to. So. There may be a customer, event handler, vendor. Event handler, or a sales order event, handler, if you, need to subscribe to, an event on the sales owner page. Suffix. The code unit name in exactly, the same way as you have done with, the class code unit. Let. Us summarize, a few intrinsic. Characteristics. Of an event handler code unit an. Event. Handler code unit should only always, refer to one object, so. You need one event, handler code unit per object that, is relevant for you the. Subscription, functions, should have the exact, same name as the trigger or the event, publisher, it refers to so. They should be called on after, insert on before. Validate name on open page and so on, since. The context, is established, to the fact that the event handler code you need only first to one object you. Don't need to duplicate, its name as for, instance in customer, on after insert. As. We have seen there, is no business logic inside an event handler code unit the, event handler only subscribes, to an event but does not contain any business, logic code it, points, the execution. Of the method to the respective, class code unit. We. Have learned that we should always respect the run trigger parameter, and the fact whether a record is only temporary or. Persisted, in the database. Let. Us now look at the basic characteristics. Of a class code unit, much. Like the event handler code unit the, class code unit always only refers to one, object in this. Case a, table, object it. Is not more than a collection of additional, methods that you have developed for the original, class in. Our example, the customer table, since. There cannot be any. Individual. Code in Microsoft, based app objects, anymore they. Need to be moved from the table to an object, in your number, range. The. Class code it also does not contain any business, logic it, just declares the additional, methods and points, the execution. To the respective, method code units which, have been called from the original table before. Needless. To say that all of this can be handled in a much cleaner way through, table extensions, and page extensions, in Visual Studio code al. Let. Us briefly focus, on naming conventions, a class. Code unit name consists. Of the following elements the. Name of the original table for. Instance customer. The. Epithet, class. And. Your. App acronym, as a suffix, to make the name unique, for. Instance my C this. Leads to the name customer class my C suffix. In the app acronym, is preferable. To prefixing, it if you. Prefix, all of your variable, declarations, will start with my C making. The code quite unreadable. Unfortunately. There are severe limitations. To the string length of object, names, this. Will make odd abbreviations. Necessary, every now and then an example. Would, be the financial charge, of MIMO header class. It. Is advisable, to take the time to look for established, acronyms, on the Internet also. Make sure to always include, the epithet, class, so, that you can filter easily, on all class code units. The. Naming conventions, of event handler code units are much the same so, that you arrive at a composite, name of customer. Event handler, myc. Limitations. Of the string length of object, names have, an even greater impact here, since, the epithet event handler runs longer, than the epithet class. Make. Sure to always include at least the, abbreviated, form handler, so. That you can easily filter on all event handler code units. This. Example shows a few class and event handler code units. Please. Notice that the object IDs, are just by way of example. Object. IDs will come from your own unique, Cloud number, range in the 70 millions if you, run an extension, that is only available in the cloud, or. They, will come from your own CF, MB number range if you have a CF MD solution, that you can run in the cloud and. On-premise. Reseller. Writing. Tenant specific, extensions. If. You already have, an on-prem product, developed, in CA l that you want to turn into a business central app you. Should consider, this two-step, approach. Redesigning. Its architecture. To an event based approach, in CA l is, a very, good preparation for moving it completely, to a visual studio code al extension.

It. Will teach you how to approach, the event based paradigm, and it. Will reveal any issues, in your code that you will need to refactor. Afterwards. It will be much easier to lift your event based on Prem product, to, studio code al. This. Concludes our course on movin your code to events to. Learn more about how to build and publish apps with Microsoft, Dynamics 365, business central follow, the link on the screen. Thank. You very much for, your attention.

2018-09-29 09:39

Other news