Writing for Extensibility

Any solution we write should be written in a way that it is extendable with minimal impact on the existing code. When writing a solution as an Independent Software Vendor (ISV), it is critical to avoid situations where our customers are forced to use inelegant workarounds in order to make the vertical solution fit their specific requirements.

Writing for extensibility takes the form of writing delegates, with relevant and careful consideration of whether to assign private, protected, or public to our methods. We would also split out code into more methods, which is good practice in any case but also serves a purpose in enabling Chain of Command. The recipes in this chapter are focused on topics that help us create extendable solutions.

In this chapter, we'll cover the following recipes:

• Writing and using delegates
• Using the attribute framework to...

Technical requirements

You can find the code files of this chapter on GitHub at https://github.com/PacktPublishing/Extending-Microsoft-Dynamics-365-Finance-and-Supply-Chain-Management-Cookbook-Second-Edition/blob/master/Chapter%206.axpp.

Writing and using delegates

Delegates are written specifically for other parties to hook into our code. This is either through an extensibility request, or because we envisage that it will be required. All the events in the tables are actually delegates, and if we write a delegate on a table, they will also appear in the events list.

One thing that delegates can't do is return a value, and we will use an example where information is passed back to the caller from the delegate. This is done by passing a value that is passed by reference—such as a table or a class.

In our example, we will write a delegate to be called when the status changes.

How to do it...

Although delegates can be written with a simple set of...

Using the attribute framework to construct classes

In Chapter 4, Working with Form Logic and Frameworks, we wrote the ConVMSVehicleServiceTableType class. This had a method that determined whether or not the record can be edited. It used a CanEdit method, which in turn called a CanEditStatus method. There was nothing obviously wrong here, but what if our customer wanted to add a status? They could use Chain of Command, which is okay, but this also means we didn't design the solution to be extended in this way. There are two ways to structure the logic in this case:

• Use a switch statement on the status
• Write a class per status that is constructed based on the record's status

The latter option is used by SalesLineType. This is much simpler to read, especially when the code in each case is more than one line. It is also much easier to extend. The traditional way to write...

Creating a purchase order programmatically

This recipe focuses on the creation of a purchase order in code. This is actually the first of three recipes that will extend our service status change handling over the next few recipes into a framework that allows the functional consultant more control over the business logic that is executed. One of the problems in solution design is that the business rules are often coded into the solution, and each iteration in the implementation evolves these rules and results in a change to the code. Writing business logic in a succinct class designed for that purpose results in code that is easier to read, maintain, and change. One common problem is when we are asked to write code that links user-defined data to code. Here's an example:

When an item of the Audio Item Group is bought from an import vendor, it must print the Audio specification...

Creating a facade

The previous recipe requires an amount of preparation in order to be called, and in these cases, we would often write a facade to simplify the class's usage. They usually consist of one or more static methods for each use case that is required. Although we will have a specific use case, they are usually generic. To see examples of facade classes in standard code, type type:"class" facade into Application Explorer's search text box.

For more information on searching in SCM, please see the following links:

• Metadata search in Visual Studio: https://docs.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/dev-tools/metadata-search-visual-studio
• Filtering Application Explorer: https://docs.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/dev-tools/application-explorer

The facade will be specific to a target service class (in our case...

Defining business actions in data

So far, we have thought of extensibility in terms of other developers; this enables them to extend and augment our code safely and easily. What happens when we want different actions to occur based on something known at runtime? The traditional method would be a series of checkboxes on a parameter form, and the code would have conditions that would be written to test each of these settings.

Another option would be to allow the consultant to add features in a plugin pattern, for example, deciding on which code should run under what condition.

The pattern for this would be to have the following components:

• A base enum that is used on the user interface: the type of action required
• An interface so that we can write code without the actual concrete implementation
• A service class to allow us to construct and interact with the concrete implementation...

Creating a SysOperation process

This framework provides a simple method to allow us to write routines that can be synchronous or asynchronous with no further effort to allow this to happen.

The complexity in creating a routine that is run in a batch process is how to store the various parameters that the routine may require. This was done in the previous version using the RunBaseBatch framework. This older framework stored this data in a loosely typed blob, and required special handling should the developer add or change the parameters. It had other problems, including the fact that the data and process were tightly coupled.

The SysOperation framework provides a new and simpler way to create processes. It decouples the data (or parameters) from the process by using a data contract. The data contract is a class that is the parameter for the entry point to the class that performs...

Adding an interface to the SysOperation framework

We can do a lot by just decorating the contract data methods but, sometimes, we need more control. This recipe steps through adding more control to the user interface created by the SysOperation framework.

Getting ready

We just need an existing SysOperation process class that we wish to add a customized interface to.

If you are following on from the previous recipe, remove the SysOperationControlVisibility attribute from the VehicleId data method.

How to do it...

To add the user interface, please follow these steps:

1. Create...

Using SysOperationSandbox

The SysOperationSandbox class provides a way to start a process that doesn't block the client. Any long-running process will show a message that states the system is busy and does not allow the user to cancel the process. The SysOperationSandbox allows a process to be started that the user can cancel, which causes the process to abort and roll back.

To do this, we need two static methods: one that initiates the process and one to act as a callback class that the framework will call to perform the desired action.

This is only suited to processes that we expect to take over a minute. We will adjust our vehicle group change class to make it use SysOperationSandbox.

How to do it...

To use SysOperationSandbox...