Overtech Wiki

Development

Third-party developers can author plug-ins for ContactsLaw by downloading the latest version of the ContactsLaw Integration Assembly (ContactsLaw.Integration.dll) and referencing the assembly in their own class libraries. Plug-ins must be written for the .NET Framework version 3.5 (or above) but may contain or reference unmanaged code.

Functionality is added or extended by implementing one of the integration interfaces in the prescribed manner.

All plug-ins must provide an implementation of the IPluginDescriptor interface - ContactsLaw will attempt to locate an implementation of this interface when it loads the plug-in, and will use this to get the name and description of the plug-in.

The following are the primary top-level interfaces that can be implemented:

• IAccountBalanceProvider - for providing opening balances on accounts from other systems.
• IContactImporter - for adding a file format or import source for contacts.
• IContactExporter - for adding a file format for exporting contacts.
• IDocumentProvider (IDocumentPreviewer, IDocumentActions, IFaxDocument, IPageCounter, IConvertToPDF) - for adding support for a new document format.
• IEmailMessage - for adding support for e-mail registration from third-party software.
• IEmailMessageProvider - for direct integration with third-party software to 'send' e-mails to ContactsLaw.
• IMainMenuItem - for adding entry-points to third-party features on the ContactsLaw main menu.
• IPaymentExporter - for exporting electronic payment details to internet banking portals and transaction processing systems.
• IPhoneController - for adding support for additional types of telephone systems.
• IPrintedReport - for adding additional printable reports.
• IReportGenerator - for adding support for report generation in additional formats.
• ISearchProvider - for allowing third-party features to interact with the ContactsLaw search.
• ISharePointOperations - for adding support for different versions/variants of Microsoft SharePoint.
• ITaskProvider - for allowing third-party plug-ins to generate tasks in ContactsLaw.
• ITaskExporter - for exporting ContactsLaw tasks to third-party applications.
• ITemplateEditor - for exposing in-place editor functionality for templates.
• ITemplateProvider (ITemplateProviderOptional) - for adding support for a new document template format.

Other important interfaces include:

• IContact - models a contact and all related data. You do not implement this interface; rather, objects of this type will be passed to your code by ContactsLaw.
• IFile - models a file and all related data. Again, you do not implement this interface yourself.

Plug-ins are loaded into ContactsLaw on application startup if they are placed in the program's plug-in directory (user-configurable). They will not, however, be included in software deployments unless submitted to Overtech Technologies for review. At our discretion, we may elect to add third-party plug-ins to our automated deployment system (see DDM).

Handling configuration in plug-ins

There are two supported approaches to handling configuration of plug-ins. For per-user configuration, you can implement the IPluginConfiguration interface; this allows your plug-in to display its own configuration UI and save the configuration to a local file - you can use any representation, however the standard .NET settings mechanism is preferred. Users configure the plug-in via the application settings screen.

For practice or company-wide configuration, implement the ISettingsProvider interface. This allows you to declare additional global application settings which will be stored in ContactsLaw's database (and therefore applied to all members). Callback methods to get, set, commit and revert settings are passed to your class when ContactsLaw starts. The simplest approach to implementing the interface is to return instances of BaseGlobalSetting, the primary implementation of IGlobalSetting.

Using plug-ins to create new activities in ContactsLaw

You can define new types of activities in ContactsLaw; you implement several interfaces that comprise the definition, then provide your own GUI for the activity itself.

If your activity operates upon its own types of records, you must implement the storage of these records and implement both the IRecordType and IRecordIdentifier interfaces to enable ContactsLaw to interact with them.

You define the activity itself by implementing the IActivityType interface; this determines the semantics of your activity, the type of record it operates upon and how ContactsLaw should treat it. Given an active instance of the activity, it must be able to start the GUI for the activity.

Your activity type implementation will be assigned an object of type IActivityInstance. This object describes the record being operated upon, the workflow action (e.g. request, authorise, process) to perform, directives passed to the activity and a reference to any task that may exist for the item. It allows you to determine which directives will be passed back to ContactsLaw and lets you finish or cancel the activity.