​The Cloud Connector for Microsoft Office 365 and SharePoint 2010 connects almost any on-premise data source, e.g. ODBC, OLEDB, OData, Microsoft .NET based providers, Files (Excel, XML, CSV), SQL databases like SQL Server, Oracle, MySQL, IBM DB2, IBM AS/400, IBM Informix, Notes, SharePoint, Exchange, Active Directory, Navision, SAP and many more directly to native SharePoint lists and libraries in the Microsoft Cloud - or any other Microsoft SharePoint 2010 installation - in just minutes without any programming. For any questions please use the FAQ Web Formor contact sales@layer2.de directly.

​It's fairly easy to build extranets for your clients, vendors or other partners with SharePoint Online or Office 365, e.g. for collaboration or mobile access. Compared to adding your partners securely to your internal infrastructure (e.g. Active Directory), a cloud-based extranet could be the better approach.

But take care about new data islands! You can easily connect some pre-selected parts of your locally existing data and documents with the new extranet in the cloud using the Cloud Connector for Office 365 and SharePoint Online. The connector keeps the data and documents up-to-date automatically in background.

This FAQ gives a step-by-step example how to do this.

​Possibly you don't want to publish all your documents to the external cloud. You can use an additional field to mark documents for publishing to the cloud-based Extranet and create a view for this. In our sample we use a view "ToExtranet" that only shows documents with the additional field "Extranet" = True.

 

 

You can create a view to filter the documents to transfer.

 

 

​With the Cloud Connector Connection Manager (a MMC snap-in) you have to setup:

1. the connection (e.g. uni-directional with overwrite, scheduling etc.),

2. the data source (your Intranet view ToExtranet) and

3. the data destination (in Extranet, the library must be created manually before).

You can use auto mapping to connect the fields of both data entities or map fields manually.

See here for sample connection settings:

Fig.: Sampe Intranet-to-Extranet one-way connection.

Please note:

• Bi-directional connections are supported as well, if required.
• If overwrite destination is enabled, non-matching entries in the destination are removed with initial sync.
• Please enable schedulung later on, when all settings are verified and you have an idea of replication duration. Duration time depends on bandwith, performance of source and destination, document size and number of documents. Only changes are transferred.

Before running the connection, you have to define the data source and destination.

Fig.: The CSOM Provider is used to connect to the data source, e.g. a SharePoint on-premise.

Please note:

• The view "ToExtranet" is given as data source in connection string.
• Windows authentication is used to connect to the Intranet.
• You don't have to enter a primary key, SharePoint document IDs are used by default.
• Please verify all settings before save.
• The data source could also be in the cloud. Cloud-to-Cloud conenctions are supported as well.

Next you have to define your data destination:

Fig.: Data destination sample, a library "Extranet" in the Office 365 cloud.

Please note

• The destination can be an on-premise SharePoint as well or any other hosted SharePoint 2010 sandbox.
• No installation required on both sides, source and destination. The Cloud Conenctor runs somewhere in your network as a windows service, e.g. on any Windows Server or Client (Windows 7).

If all settings are verified, please go to connection root and run the connection manually first. Please note,that it cloud take some time to transfer all documents. You can take a look in your cloud library to see how it goes on.

​Now take a look at your extranet. The pre-selected documents are in there, after running the connection.

Fig.: Sample data destination in the Office 365 cloud.

Please note:

• Selected documents are transferred only.
• Metadata like date / time of creation or last modification can be kept for extranet, if required by field mapping.
• The user mapping is more complicated. It would work only in case, user information like "Created by or "Last modifed by" would exist in extranet with the same tokens. If it does not (more likely), you can create some other column for that (e.g. "Originally created by") and map the fields to this column for information.
• Changed files are transferred only on update. That means, you can define change subscriptions per-email or workflows in the cloud without any restrictions.