composite_c1_integration_with_composite_c1

Composite A/S

Nygårdsvej 16

DK-2100 Copenhagen

Phone +45 3915 7600

www.composite.net

Integrating wi th Composite C1

Composite May 2008

of 15 Integrating with Composite C1

Contents

1 INTEGRATING USING COMPOSITE C1 .............................................................. 3

1.1 The setup 3 1.2 Scenario 1: Front-end rendering integration 3 1.2.1 Advantages 4 1.2.2 Disadvantages 4

1.3 Scenario 2: Simple data-level integration 4 1.3.1 Advantages 5 1.3.2 Disadvantages 5

1.4 Scenario 3: Bi-directional data-level integration with field mapping 6 1.4.1 Bi-directional data-providers 6 1.4.2 Field mapping 6 1.4.3 Advantages 7 1.4.4 Disadvantages 7

2 AN EXAMPLE – MOSS 2007 ................................................................................. 8

2.1 Prerequisites 8 2.2 The philosophy 8 2.3 The process 8 2.3.1 Step 1 – Creating the datatype 8 2.3.2 Step 2 - Modifying the datatype and its fields 12 2.3.3 Step 3 – Editing external content 13


1 Integrating using Composite C1

Integration can be done in numerous ways – from the simplest (and least flexible) to the most advanced, bi-directional business-process supporting setups. In the following few chapters, we will be focusing on a mock-up of integration between Composite C1 and Microsoft Office SharePoint Server 2007 (MOSS 2007).

1.1 The setup

In the following few chapters, we will be working in an environment consisting of a CMS publishing content to a website and a MOSS publishing content to a SharePoint Portal.

The layout of the website is managed in the CMS and the layout of the SharePoint Portal is managed in MOSS.

Editors in the CMS are working only in the CMS. SharePoint editors are working only in the MOSS (although in reality there might be some editors working in both environments - the strict separation is used for explanatory reasons).

Data redundancy is not accepted.

1.2 Scenario 1: Front-end rendering integration

The easiest way of integrating a CMS with an external source is by creating a rendering (XSLT or UserControl) that is able to extract content from the external source directly. This rendering is then inserted into the template and/or page layout directly, bypassing the internal content structure of the CMS.


1.2.1 Advantages

Very easy to create

Has no influence on the editors’ daily work

1.2.2 Disadvantages

Bypasses business logic and editor rights

Can only be created and modified by a developer

Data and presentation are tied closely together

Content can only be edited in MOSS and is not visible in the CMS backend.

1.3 Scenario 2: Simple data-level integrat ion

Instead of extracting data into a rendering directly, many systems are able to do a sort of data-level integration. The typical setup includes a data provider, by which the MOSS data is imported into the CMS – and thus regarded as its “own” data in the rendering scenario.


Typically, the CMS is not able to interpret what data is coming into the system from the external source. It is merely regarded in somewhat the same manner as a media-type file (PDF, MS Word Document, JPEG, BMP and similar). The CMS is able to render the content, but it is not editible and will not be a true part of the content structure within the CMS.

1.3.1 Advantages

Compared to Scenario 1, this scenario offers a greater flexibility for Site Developers. They will be able to build more generic renderings that can be inserted into the layout structure of the website much in the same manner as “normal” renderings. By using this method, front-end web designers may be able to modify the location of the external content (by placing the rendering in the right location within the layout structure) and might even be able to modify the overall look and feel of the rendered content through CSS modifications.

A certain level of business logic can be included in the setup, allowing some user restrictions etc for the external content.

1.3.2 Disadvantages

Compared to Scenario 1, this scenario is typically a little more costly. Vendors using this type of integration do not typically have pre-developed data providers. This means that these will have to be developed on a per-use basis (no reuse is possible).

The setup will not allow integration with third-party mediators (like Microsoft BizTalk, Software AG’s EntireX and the like) as these require a field-mapped structure.

The integration is not bi-directional so content stored in MOSS cannot be edited from within the CMS.


1.4 Scenario 3: Bi-directional data-level integration with f ield mapping

This setup is in many ways established as Scenario 2. However, some very important features are added to the setup:

Bi-directional data providers

Field mapping

1.4.1 Bi-direc t ional data-providers

Bi-directional data providers will allow the CMS (and thus its editors) to modify content stored in the MOSS database from within the CMS directly. In fact, the editors will not have to realize the content is in fact non-redundant data from an external source. Updating the content is done in exactly the same way as “normal” CMS content – with the one difference that when “Save” is executed, the content is stored in the external source, instead of the CMS repository itself.

In cases, where a data provider is inserted into the MOSS setup as well, MOSS will be able to extract content from the CMS directly and reuse this as was this content in fact a list in MOSS itself.

1.4.2 Fie ld mapping

If field mapping is invoked in addition to the bi-directional data providers, the external data will in all ways be exposed as “normal” CMS content. This exposure is not only on an editor level, but all developers working with renderings and functions in the CMS will have the same access to the external data as to data stored within the CMS repository.

In reality, this means that individual fields can be selected for rendering, and data can be sorted and structured – and in all ways modified – using the internal functionality of the CMS.


1.4.3 Advantages

Truly integrates content from external sources

External data editable by editors within the CMS

Data fully exposed for developers as CMS native content

Complies with business rules and security restrictions (if these differ from the MOSS and CMS environments)

Once the generic data provider is created, it can be reused throughout the site (and multiple sites). Such data providers are often provided by the CMS vendor.

1.4.4 Disadvantages

Creation of data providers requires CMS specific knowledge on the data level

If no data provider is present, it might be costly and/or time-consuming to develop


2 An example: MOSS 2007

This chapter contains a mock-up of integration between Composite C1 and MOSS 2007 based on Scenario 3 in the above description.

2.1 Prerequisites

A Composite C1 specific data provider connecting Composite C1 and MOSS 2007 is present.

2.2 The philosophy

A Global datatype in Composite C1 is field-mapped to a set of fields in a MOSS list using a bi-directional data provider.

The labels (Composite C1 field names) and input widgets are specified in Composite C1, thus allowing a setup where all content in MOSS can be edited in the correct manner in Composite C1.

All content is regarded as native Composite C1 content once the following example has been carried through.

Estimated time for setting up a connection and doing the field-mapping is 5 minutes.

2.3 The process

The process consists of 3 steps:

1. Creating a datatype 2. Modifying the datatype and its fields 3. Editing external content

2.3.1 Step 1: Creat ing the datatype

Creating a datatype for external integration is done in exactly the same way as a “normal” datatype is generated. In this example, we will be creating a Global Datatype – where the content will be available throughout a website or a site farm. The same process applies for page data (page-specific datatypes) and metadata types.

In the Data area right-click to add a new data-type:


This will invoke the Add data type workflow in Windows Workflow foundation. Please note that all actions in Composite C1 are controlled through a Windows Workflow, and all forms and dialogue boxes are defined using a XAML-like markup language. This means, that any interaction can be modified to suit individual needs. Such needs might be bespoke interactions with third-party systems.

In this instance, the Add datatype workflow invokes a wizard based creation workflow.

The first step is to apply general information, such as the name, namespace and title of the data type. This information is used afterwards for display in the tree structure and exposure in i.e. IntelliSense in Visual Studio.

The final part of the first wizard step is to select which data provider to use. Default is the Composite C1 data provider, which will store content in the native Composite C1 repository. In this example, we wish to use a data provider for MOSS 2007, which is therefore selected in the list:


Selecting this data provider will move the workflow in the direction specified for the MOSS data provider. In other cases, the following steps of the Create Datatype workflow may appear different, since there might be other relevant data to collect.

For MOSS, the first thing the data provider needs to know, is which server to hook into. In most cases, a username and a password is necessary as well.


Once the workflow knows the URL for the MOSS server, it can automatically look up exposed lists on this server, and populate a drop-down allowing the user to select the specific list from which to get data:


Usually, when generating a datatype in Composite C1, the user needs to define the fields for the specific datatype. When integrating with external systems, this is not necessary, as all field definitions are extracted from the external system.

So, after these three steps, all the user needs to do is click “Finish”, and the datatype is being generated in C1 – with a bi-directional integration to the MOSS server.

2.3.2 Step 2: Modifying the datatype and i ts f ie lds

Once the datatype has been created, the basic information and the fields can be modified. Especially the ability to modify fields is interesting, since this allows a true field mapping between the two systems. In reality, this means that a field named “A” in MOSS can end up being named “B” in Composite C1, as other labels may apply in the SharePoint Portal and on the Website.

Editing the field properties is as easy as if it was a “normal” datatype:


The properties of a “virtual” field in Composite C1 include the ability to select which input widget to use for editing the field-specific content. In comparison to the “normal” datatypes in Composite C1, the validation and field-type settings are left out, as these are defined in MOSS.

2.3.3 Step 3: Edi t ing external content

Once the first two steps have been carried out, the external content appears in any way as native Composite C1 content. For developers, all fields and properties are exposed – in Composite as well as in i.e. Visual Studio (including IntelliSense) – and for editors, editing content is done in the usual manner. Right-click and edit (or use the context-sensitive top menu):


Naturally, there is no data redundancy. Clicking “Save” will result in a save action storing content in MOSS – not in a replicated environment in Composite C1. Adding a new item in MOSS will result in a new item in Composite C1 as soon as the tree refreshes.

composite_c1_integration_with_composite_c1

Documents

moss data

composite c1 integration

rendering integration

extracting data

sort of data

data provider

developer data

data redundancy