Duet Behind the Scenes: Metadata Driven Solutions

The Duet applications are built using metadata definitions that are interpreted during runtime and drive the different application’s workflow and UI.
How is Duet’s metadata defined and used? What are the advantages of this model?

Presentation Objects

The Duet metadata defines business objects and how they interact with the user and the backend system. I like to refer to such objects as “presentations objects” because unlike the backend Business Objects that make sense to backend developers these are objects that make sense to the user.
For example, information about a person’s salary, compensation and HR information may be represented as several different business objects on the backend (or on several backend systems, maybe even from different vendors). The end-user, looking at a contact information on his Outlook doesn’t have to know about all the different backend and business objects that were used to aggregate the information on his screen.

Therefore, the Duet metadata defines such presentation objects - the information they carry, how this information is aggregated to and from the backend system(s)and how they interact with the user in his Office environment. So, from an abstract point of view, an application’s metadata structure is somewhat similar to this:

DuetML

All the UI components in Duet are defined by a markup language – DuetML. Each UI component displayed to the user is actually represented by an XML defining the UI and a .NET assembly codebehind defining the logic behind the UI. Basically this mechanism is a lot like WPF’s XAML but with several key differences:

1. DuetML is based on top of WinForms and has very limited UI capabilities specifically designed for Duet’s UI screens
2. XAML gets compiled (to BAML) during design time while DuetML is interpreted during runtime.
   This gives us a lot of customization & translation capabilities on the server where we process the DuetMLs before sending them to the user (I will probably have to dedicate a whole post specifically to discuss business customization and localization)

In fact, DuetML’s schema was designed to closely resembles XAML to allow transition to XAML in the future…

So, Why Use Metadata?

Simplified solution development. The metadata-based architecture makes it possible to develop declarative business solutions. Because solutions are defined in metadata, developers can build simple, powerful solutions with little or no coding using pre-made common solution building blocks. Advanced developers can use .NET further customize their applications and add new features.

Centralized deployment. In order to run Duet solutions all the clients need is the Duet runtime which is a generic add-in that runs inside the Office applications and can load and interpret the metadata fetched from the server. The different solutions are deployed on a central server and do not require additional installations on the client.

Enhanced customization capabilities. Declarative approach also allows enhanced customization capabilities as customizing the application simply means editing its metadata. Duet’s ACE (Application Configuration Environment) goes a step further by allowing providing a configuration environment that allows the business administrator to apply such changes without requiring knowledge about the metadata and code behind a solution.

Automatic generation and modeling. A declarative approach for defining solution is the basis for enabling modeling and automatic generation of solutions. Imagine that you could quickly select some objects from the backend, define the matching object in Outlook and the data you wish to see and a solution will automatically be generated for you? And imagine you could customize such a solution using a visual programming tool such as Visual Composer (Microsoft Popfly, Yahoo Pipes style of development for you non SAPers)