Keep up to date with the Symphony Framework by subscribing to the mailing list.

Check out the new Symphony Framework Academy! It’s the home for information and tutorials to help you get the most from the Symphony Framework! Click on the Academy option below.

Symphony Framework


The Symphony Framework provides software developers with a number of opportunities to enhance and expand their Traditional Synergy and Synergy .NET applications.

Symphony Conductor


The Conductor namespace is the powerhouse of the Symphony Framework. Key features include the Synergy DBMS thread-safe data access layer, Windows Presentation Foundation (WPF) visual state navigation control, thread management utilities, Synergy data type conversion capabilities, and the Symphony Data Object. This is the central component of the Symphony Framework providing a number of key features including:
  • Symphony Data Object. The Data Object is at the core of the Symphony Framework. It provides the connection between your Synergy data and the outside world. Although the name may suggest it, a Data Object has no concept of the source of the data it is holding and exposing. The programmer may load the data from a file, database, memory, or a remote web service – the data object simply exposes it. The Data Object is code generated (using CodeGen) from a repository structure but is not just a wrapper for the data as it provides a lot of additional functionality, for example:

    • Performs field level data validation as per the rules defined in the Synergy repository. Required fields are validated, ranged values are checked. The Data Object also provides hooks that allow you to perform additional validation as the data is changing.

    • Provides object validation. The Data Object provides properties that indicate the status of the Data Object. The IsDataValid property indicates of all the data within the object is valid – passes the standard repository validation and any custom validation. The IsDataModified indicates if the data has been modified from its original state. IsNew is a property that indicates the Data Object is new and has no data within it.

    • Each Synergy data field defined in your repository structure is exposed as a read/write property. The base Data Object class implements the INotifyPropertyChanged interface so that any consuming client will be able to react to changes to the data. This is a standard across WPF, Universal Windows Platform (UWP), and device application using Xamarin Forms.

    • Associated with each data field from the repository structure, the class also exposes IsReadOnly and IsEnabled properties that allow you application to control the editable state of the data within your Data Object. Methods within the Data Object allow you to simulate the set processing techniques within the Synergy UI Toolkit to change the states of individual fields, all fields, or sets of fields.

    • An additional HasFocus property for each data field allows your host program to request focus to a field within an edit form. The User Interface (UI) portion of your application can be written to honour these requests and move field focus as required. A user interface built using Symphony Styles implements this focus change capability.

    • If defined in the repository, the Data Object will also provide properties that allow access to additional static information such as:
      • Field heading – the report headings defined for each field in the repository structure.

    • Implements the IComparable (defines a generalized type-specific comparison method that a value type or class implements to order or sort its instances) methods that allow the Data Object instances to be sorted. The .NET Framework is unaware of Synergy types such as Alpha, Implied Decimal, etc. so the Data Object provides the ability to sort on these unknown types.

  • Thread safe processing. Synergy .NET and the .NET Framework bring with it the ability to perform multiple tasks simultaneously on different threads within your applications process space. Elements of the core Synergy environment – such as data file access through xfServer – require protection against cross thread operations. The Symphony Framework provides a number of classes that ensure complete thread safe operation.


Namespaces within the Symphony Conductor assembly:

Commands. The Commands namespace contains a number of routed commands that allow you to bind logic to actions. All the command classes extend the ICommand interface. Actions are defined on the UI as, for example, the click of a button or the click of an item in a data grid. When the action in the UI happens, the logic assigned to the command is executed.

Content. The Content namespace contains a number of simple classes that expose collections Symphony Data Objects. These collections can be loaded with Symphony Data Objects and presented to UI controls that retrieve static and dynamic data such as drop-down lists.

Converters. This is a powerful area of the Symphony Framework. When building components of your applications using Synergy .NET you have access to the whole Microsoft .NET Framework. However, this framework is unaware of the code Synergy types like alpha, decimal, and implied decimal. The classes within the Converters namespace provide the ability to convert between the standard Synergy types and the appropriate .NET types. For example, you can easily convert between a Synergy alpha and .NET string types. The converters work in both directions and can be imbedded into the exposed properties of the Data Object class, or used when binding data between your application and the UI controls. Together with the simple converters, there are also a number of advanced converters that allow you to arrange your Synergy data into the appropriate types expected by your WPF UI or consuming code. For example, there are converters that will convert between a Synergy decimal field and a DateTime type. Legacy systems often contain simple data that need organizing into modern types. For example converting “Y”/”N” fields into a Boolean type.

DataIO. This namespace contains a number of classes that provide thread-safe access to your Synergy data files. All the required thread management is performed, as well as providing all the required functionality. The core FileIO class provides all the required methods to access the data within an indexed and relative file. Data inside your Data Objects can be processed directly by your FileIO objects without needing to convert them.

Framework. The original concept of the Symphony Framework is to provide the ability to migrate a Synergy UI Toolkit application and WPF. One very important aspect of the UI Toolkit was Environment processing. One area of Environment processing was the ability to store away the current “visual” state, bring new window controls into view and then after processing them the application can exit the visual state and the original visual state would be restored. The Framework namespace contains the same ability within the UIStateStack class. This class allows you to navigate between visual states defined within your WPF visual controls. For more details about visual states refer to the VisualStateManager class in the Microsoft documentation pages.

Model. This namespace contains the code DataObjectBase. This is the cornerstone of any Symphony Framework based development. Additional classes within this namespace allow the developer to communicate between data objects and your existing Synergy application logic.

Static. To provide the Synergy developer with an easy way to process multiple tasks across multiple threads the Symphony Framework contains a ThreadSafe class to manage thread processing.

ViewModel. To conform to the Model-View-ViewModel (MVVM) design pattern the Symphony Framework contains a base View Model class. The BaseViewModel class contains properties that expose state navigation commands that can be called directly from code or bound to events or actions within the UI. When incorporating a new WPF interface into your existing UI Toolkit applications the BaseViewModel class provides the ability to raise UI Toolkit menu signals back to your Traditional Synergy code. These can then be bound to existing menu processing logic.

CodeGen WPF based Templates


The CodeGen installer delivers a large number of Symphony related templates that allow the rapid generation of code and components to build powerful WPF desktop applications. These include simple page and grid layouts presenting structure based fields to complex maintenance programs of Synergy data including full selection and data navigation capabilities.

Code generation also provides the ability to generate “style” files. These style files utilize many of the field properties stored within the Synergy repository to build styles that describe both the prompt and field display attributes. These styles are recognized directly within the Visual Studio XAML editor and provide rapid development of your User Experience (UX):

Simple references to the style in the XAML code provides the complete user interface experience:


Symphony Framework UI Toolkit


The Symphony Framework UI Toolkit namespace has been designed to assist with the migrations from traditional Synergy UI Toolkit screens to a Windows Presentation Foundation (WPF) implemented desktop application.

The migration path from UI Toolkit to WPF utilizes a number of core Synergy and .NET capabilities as well as the Symphony Framework and utilities such as CodeGen.
A typical UI Toolkit program comprises a number of execution steps:

  • Load the required UI elements such as menu columns and input windows.

  • Build, in code, additional UI elements such as toolbars and selection lists.

  • Define the screen layout by placing and arranging menu columns, input windows and selection lists.

  • Process a specific UI element (input processing, list processing) and respond to any events the control raises. The control processing terminates when the event is raised. The event is honoured and processing of the UI control restarts.


The important element is that the program retain control at all times.

In the WPF application the structure is slightly different. The UI component is defined entirely outside of the program code. The program code makes the UI available and waits for events. When the UI returns, the program is closed. The program no longer has control.

The Symphony Framework UI Toolkit provides the boilerplate code to enable the seamless communication between your WPF user interface and the existing application code.



The original UI Toolkit program provided standard menu capabilities along with a graphical toolbar.

The main application “window” was a tab container presenting a number of page type including grids and input forms.


The replacement WPF implementation uses the same Traditional Synergy host program:



The new user experience included:

  • A modern Microsoft ribbon menu control.

  • A Microsoft Outlook style navigation bar.

  • Powerful grids the include in-grid filtering and grouping of the data.

  • Tab panels that can be dragged/floated and dropped to any location within the application.

  • Field and panel level data validation with graphical error indicators.


Standard themes can be applied to the application:



Symphony Harmony and Symphony Bridge


Symphony Harmony takes the basic concept of the Data Object and wraps it with the ability access data and logic in a SQL base fashion on a remote server. Industry standard protocols are used to enable client server connections in both in LAN and WAN environments.

Enabling logic and data access on a server from a device is a fundamental requirement for any application. The Symphony Harmony and Symphony Bridge namespaces empower the developer to continue to harness the power of their existing Synergy logic on these portable devices. Utilizing standard HTTP/HTTPS communication protocols, Windows Communication Foundation (WCF) restful services and JSON serialization the Symphony Bridge service provides access to Synergy logic and data using Symphony Data Objects.

Symphony Harmony is a namespace that manages data and logic execution via Symphony Bridge. The Harmony namespace provides methods to perform standard data manipulation tasks such as select, insert, update, and delete. It also provides access to remote logic using an SQL stored procedure structured implementation.

Security in todays distributed computing environment is of paramount importance. The Symphony Bridge employs standard HTTP and secure HTTPS protocols to enable communication between client and server. Additional levels of security have been built into the Bridge server—methods must be attributed to prevent malicious execution of none-attributed logic.

Migrating Synergy logic from a procedural, process-based application brings with it several considerations including the use of common and global data, hard-wired channel numbers and none thread-safe xfServer data access. In a multi-threaded environment this can cause a multitude of problems. The Symphony Bridge Server addresses all of these issues by encapsulating the execution of the logic into application domains and managed threads.

Via Symphony Bridge, the Symphony Harmony namespace uses Symphony Data Objects to communicate data between client and server. Synergy repository based Data Objects can be passed to the server, along with standard Common Language Runtime (CLR) types. All methods return a collection of Data Objects.

To enable complex data elements the code generated repository structure Data Objects can be extended to include both individual and collections of other data objects. This allows a single method on the server to return a collection of complex Data Objects. For example, a collection of order headers and associated order line items for each header together with extended supplier details. This extensibility is a powerful way of communicating data between client and server.

The Symphony Bridge is a pre-built Windows Service so there are no requirements on the developer to understand and develop server programs, methods or protocols. Develop a class, implement the required methods, and apply the required security attribute and place the resulting assembly in the required folder is all that is required.

A physical or virtual machines can execute multiple Bridge servers and each can be configured independently.

Use cases


The Symphony Framework provides a number of options for the Synergy developer.

Synergy UI Toolkit Migration


The Synergy UI Toolkit is a library of routines for the Synergy developer to take full advantage of cross-platform graphical user interface capabilities. Due to the cross-platform nature of the UI Toolkit the user experience on the Windows desktop platform can be restricted. Also, the UI Toolkit is not compatible with the Synergy .NET environment. For this reason alone, a migration path from UI Toolkit to a more modern Windows Desktop user interface is required. Modern Windows Presentation Foundation (WPF) capabilities provide state of the art user experiences and the Symphony Framework offers migration capabilities that offer the ability to incrementally improve the user interface screen by screen, program by program.

Typical Synergy UI Toolkit programs have the following categories of user interface which can be developed and migrated to WPF:

  • Menu bar. The standard UI Toolkit menu bar will be replaced with WPF menu elements. These elements will be configured to replicate the existing UI Toolkit menu columns and entries.

    • All menu entries will be controlled and data-bound to GenericCommand (Symphony.Conductor.Command) based properties. This will allow for the existing application logic to retain the ability to hide/reveal and enable/disable entries as required.

    • It is not proposed to support dynamic menu capabilities built at runtime using the MB_*** routines. Within the supplied source code there are a number of programs that utilize this UI Toolkit capability. These will be modified to provide a design time XAML based alternative. The Customer Maintenance program does not utilize dynamic menu generation so this category of modification will not be present in the POC.

    • This visual menu structure can be replaced with alternate menu capabilities in the future, such as a Microsoft styled ribbon control.

  • Application toolbar. The Synergy UI Toolkit toolbar will be replaced with a standard WPF toolbar. Because there are no scripting capabilities, all Synergy UI Toolkit toolbars are built in program code at runtime. The replacement toolbar will be defined in the XAML at design time. However, the APIs utilized will allow the existing program code to hide/reveal and enable/disable the toolbar and associated controls.

    • The initial release of the POC will contain only button controls on the toolbar that mimic the buttons available in the existing UI Toolkit program.

    • Future development would enable the toolbar to contain additional control types and to be docked at any position.

  • Tab container processing. Defining and building tab containers and their associated child controls is a program/runtime activity within a UI Toolkit program. However, input window tab pages are usually defined within window scripts. This will be changed and all UI components will be defined within the XAML. This will ensure the correct separation of layers and also ensure that the correct styling can be applied. This approach also provides for the maximum flexibility with regards to screen sizing and control positioning.

    • Input windows currently defined in script files will be converted to XAML controls. The field controls will be based on Styles that will be code-generated from the Repository and associated windows script files. Information such as data type, basic validation, prompt, and other visual information, and processing requirements such as break processing, change and hyperlink methods will all be carried forward to the new WPF application.

      • Existing field/window processing techniques employed in the application, for example, to enable and disable fields, will continue to be supported. The processing and logic associated with the input forms will continue to execute as now.

    • Tab pages displaying a list will be converted to use the standard DataGrid control that ships with Visual Studio. Although other more powerful grid controls are available the POC will be built using all standard WPF controls. Future developments will be able to harness the power of third party components as required. Column sorting will be available.

    • Multi-line text editing. Any tab pages that provide multi-line text editing capabilities will be migrated to use a rich text edit control. This will immediately offer new capabilities like a built-in spell checker. Transferring the text between the edit control and the Synergy backing field will be done on an ad hoc basis.

    • Buttons. An important aspect of any UI is the ability to select processes or functions using buttons. The UI Toolkit provides the ability to present buttons on various UI controls but they are limited in size and position within the control. The XAML based UI will remove this restriction. Buttons will be styled to match the application and can be placed appropriately on the UI control.

  • Look-up lists. Many fields on the input forms take input directly from the user or via a selection/lookup list. These lists are activated by clicking the hyperlink (green prompt) for each field. The list is displayed and the user can review and select an individual item. For these fields the POC will implement the Symphony.Crescendo.Presentation.SearchTextBox that provides an editable control that displays a spy glass that when clicked can then display the associated lookup-list.

  • General message and question dialogs. Throughout a typical application message box controls are used to convey information to the user, such as “Account not found” or to request pertinent information relevant to the operation being requested, “Delete, are you sure?” These dialog controls can be changed to display XAML based dialog controls that can be styled accordingly.

The Symphony Framework UI Toolkit provide a layer of communication between the existing Traditional Synergy code and the new Synergy .NET WPF UI. This communication is in the form of a Data Object. These data objects provide access to the individual field properties to enable data binding to UI controls, and to a record based property to allow interrogation of the data from the traditional Synergy application code.

New Developments Exposing Existing Data/Logic


Function and feature rich software is the staple objective for Synergy developers. As many of our customers are represented in the top five of their chosen vertical markets the power of Synergy enables them to continue to develop powerful software solutions. Enhancing the existing logic and data by utilizing the Synergy .NET compiler and Microsoft Visual Studio development environment empowers the developer to create responsive feature rich applications for the desktop, tablet, and phone. The Symphony Framework is key to the success of this platform agnostic development. The Framework allows you to build and expose intelligent data objects from your repository based data structures. Existing routines connect to the data objects using traditional record and field based access. The new application code data-binds to instance properties offering full two-way data transfer using standard design pattern techniques. Intelligent data objects offer more than just data; they provide inbuilt field level validation, expose properties for to check for modification, validity and complete error information.

Ingrained into every aspect of the Symphony Framework is the ability to perform thread-safe processing within your true multithreaded applications. Performing multiple operations simultaneously becomes second nature. Loading data on a background thread using the Symphony Framework Data IO classes ensures that user interface notifications are raises on the appropriate UI thread. Utilities classes provide the ability to execute methods and lambda routines in the background using a single line of code, ensuring that your user interface remains responsive to the user.



Beyond the desktop


Targeting tablet and phone devices requires a different programming paradigm. Large memory intensive applications with access to Local Area Network (LAN) based data is no longer an option. Interrupted wireless and mobile networks, small application footprint, program state save and restore requirements and data sourced from could-based servers all require a different approach to “App” design. The Symphony Harmony and Symphony Bridge capabilities provide the required building block for implementing a successful device based app. The Symphony Harmony component continues to provide access to your intelligent data objects but from a pure Common Language Runtime (CLR) base. The Symphony Bridge is a powerful and efficient JOSN/BSON based web service layer offering dynamic data and logic access through standard SQL syntax to your server based application and data servers. Application Domains on the server are fully supported, ensuring your applications data remains isolated for each connecting client. State management helps you to fine tune your application server ensuring optimal response times from your always-connected servers.

Conclusion


Regardless of the target deployment infrastructure, the Symphony Framework works in Harmony with your Traditional Synergy and Synergy .NET development environments to help you maximize the investment you have made in your applications and can assist in moving them forward to new platforms offering new opportunities.