Microsoft Dynamics Road To Repeatability Technical Deep Dive Server Extensibility in Microsoft Dynamics NAV Vjekoslav Babić, MVP

About the Presenter Vjekoslav Babić consultant, trainer, blogger, author Authored 30+ “How do I…” videos for NAV 2013, 2013 R2 and 2015 Written more 300+ blog posts and technical articles Most Valuable Professional for Microsoft Dynamics NAV since April 2010 Mibuso:Vjeko Blog:

Agenda Patterns and Practices Extending through.NET Interoperability Extending through Web Services Combining.NET and Web Services Applying Patterns and Practices in server-side extensibility

Assumptions and Preconditions You know what SOAP web services are You know how to expose and consume web services in NAV You know what DotNet type in C/AL does You have basic.NET Framework and C# understanding This session is NOT: Comprehensive course about web services Comprehensive course about.NET interoperability

Why Server Extensibility? C/AL can become difficult to maintain and extend Not everything belongs in C/AL Not everything belongs in NAV

Patterns and Practices Benefits of Patterns and Practices Benefits of creational patterns Most useful creational patterns In this topic you will learn about: Importance of design patterns Creational patterns Singleton pattern Inversion of Control pattern

Patterns and Practices Everyday reality for developers in C#, Java, and many more languages Slowly taking on in C/AL world C/AL makes patterns difficult Common (non-NAV) design patterns require more flexibility than C/AL provides Many patterns can be achieved through.NET Interoperability

Benefits of Patterns and Practices Accelerated design and development Reduced technical risk Existing knowledge is leveraged Solutions are more maintainable Solutions are extensible Result in reusable code

Types of Patterns Creational Patterns Structural Patterns Behavioral Patterns

Creational Patterns Separate how objects are created, composed, and represented Increase system flexibility and extensibility Encapsulate knowledge about the classes that the system uses Hide the details about how the instances are created Two common creational patterns: Singleton Inversion of Control

Key takeaways Design patterns enable flexibility and repeatability Design patterns are commonly used in C#, and should be as commonly used in C/AL

Extending through.NET Interoperability.NET Interoperability basics Limitations of.NET interoperability System.Reflection and related functionality In this lesson, you will learn how to: Use reflection to access more.NET functionality Leverage serialization on custom classes

.NET Interoperability basics Accessible from C/AL: Classes, structures, enumerations, and interfaces Public constructors, properties, and methods Data-type mapping: Simple types: passing parameters and receiving return values Complex types: variable assignment String, DateTime, Object and Stream fully interchangeable with C/AL Limitations – fields, generics, etc.

Limitations in.NET interoperability Not available: Non-public members Fields Extension methods Delegates Generics Asynchronous execution Full compile-time type checking … and many more

Reflection Capability of.NET to gain run-time insight into objects, their structure, and functionality. System.Type is the foundation of reflection in.NET Reflection allows: Accessing normally inaccessible content from C/AL Unprecedented runtime flexibility

Example of reflection runtime flexibility Generic page-based web service proxy: 1.Reads the WSDL document 2.Imports the service description from WSDL into a code namespace 3.Generates C# proxy code from code namespace 4.Compiles C# proxy code into an in-memory assembly 5.Uses reflection to call into proxy functionality and access web services

Exchanging data: Serialization Serialization enables a class to instance to be represented in a format ready for storing or transfer, for the purposes of: Persisting state Cloning Transfer data across application or system boundaries … and many more In C/AL it is a prerequisite for exchanging data between server and client.

Key takeaways Most C# code can be translated to pure C/AL Inaccessible features can often be accessed through reflection Still inaccessible features can always be packed into wrapper classes Make custom classes serializable

Extending through Web Services A quick refresher of Web Services Web Services limitations Using XMLports in Web Services Benefits of using XMLports In this topic, you will learn how to: Use XMLports to represent NAV data as object hierarchies

A quick refresher SOAP Web Services Process-level integration Pages Codeunits OData Web Services Data-level integration Pages Queries

A quick refresher (continued…) Reading and writing of data through pages Data and process integrity is maintained, all triggers run All NAV deployment scenarios supported: Authentication modes Single/multi-tenancy SSL Cloud deployments and OAuth authentication

Some functional limitations Stateless Every call is an independent session No state sharing between calls Single-instance codeunits don’t help Unilingual NAV always responds in ENU NAV disregards the User Personalization record And some more Work date FlowFields & FlowFilters No user interaction

XMLports in Web Service Calls XMLports can be bound as parameters in codeunit web services When an XMLport is used as a parameter: SOAP data is serialized into a stream Stream is automatically bound as source or destination You call IMPORT or EXPORT as necessary EXPORT can be omitted

Consuming XMLports through SOAP When XMLport is consumed: Data structure is mapped to an object hierarchy Data is strongly-typed NAV internal structure is abstracted

Benefits of XMLports Technical: Page services cause overhead Pages represent UI; XMLports represent data XMLport services provide better support for bulk operations (create, update) Architectural: XMLports are hierarchical Data structures are more persistent than UI structures XMLport logical data structure can be more abstract than actual structure

Key takeaways All NAV functionality can be accessed through web services Web services support all deployment scenarios XMLports increase flexibility and extensibility of web-service based integration scenarios

Combining.NET Framework and Web Services Applying Singleton pattern for cross- session state management Passing object data In this topic, you will learn how to: Extend server-side functionality through combining web services and.NET interoperability. Overcome limitations of web services Pass complex and object-based data through Web Services

Singleton Pattern Makes sure that only one instance of an object exists. Various implementations in object-oriented languages. Single-instance codeunits: Closest approximation in C/SIDE They are not a correct implementation of the singleton pattern!

Applying Singleton pattern Singleton pattern enables storing volatile state on server level. Web service calls can benefit from cross-call state preservation through Singleton pattern.

Passing object data Consuming and exposing ends can use the same object structures Complex (object) data can be passed as strings: Serialized XML Serialized JSON Serialized Base64-encoded binary data Consumer serializes calls and deserializes responses Server deserializes calls and serializes responses

Key takeaways Singleton pattern allows cross-call state preservation Serialization enables complex data exchange through Web services

Applying Patterns and Practices Inversion of control through Factory and Service Locator patterns Class vs. Interface implementation In this topic, you will learn how to: Implement an inversion of control strategy to make code more extensible Use.NET interfaces to make functionality even more flexible

Inversion of Control Pattern A high-level creational pattern aiming at decoupling dependencies between code modules Various implementations Not all implementations are applicable in all environments In C/AL the following implementations are easy to accomplish: Factory Service Locator

Factory Pattern Objects are not instantiated directly, but through another object “Our” application has loose coupling with “Their” code Class instantiation is controlled at design time through code Factory has predefined knowledge of classes it can instantiate

Service Locator Pattern Objects are not instantiated directly, but through another object “Our” application has loose coupling with “Their” code Class instantiation is controlled at run-time through either design-time or run-time setup Service Locator has no predefined knowledge of classes it can instantiate

Creational Patterns Implementation Choices Base classes Simplify development Limit flexibility Interfaces Provide higher degree of flexibility Enable same objects to represent different entities (or functionality)

Key takeaways You should decouple your code from external dependencies Inversion of Control pattern provides flexible decoupling strategies C/AL.NET interoperability code should use interfaces whenever possible

Thank you!