We’ve just moved some of FoxWeave’s SaaS and Database connector implementations out to Github.

We also created a Wiki (also on Github):

• FoxWeave Component Dev Wiki

We’re hoping the combination of some reference connector implementations + wiki based developer documentation will help people create an publish FoxWeave connectors to more and more Cloud and On-Premise Apps/APIs and Databases.  Please let me know if you’re interested in building a connector for an App/DB, or know of someone that might be interested.

Please share this news with your friends on Twitter … Tweet

We published two kinds of connector “modules”:

1. Connectors for a number of Cloud Services (SaaS) – MailChimp, OnePageCRM and Zendesk.
2. Connectors for a number of Relational Databases – Oracle, PostgreSQL and MySQL.

In the last while, we’ve added some really useful features to the FoxWeave UI, all with the ultimate goal of making it VERY easy to migrate or sync data between your Cloud and On-Premise Apps and DBs.  Anyone can use FoxWeave now - you don’t need to be a “geek” !! You’ll be connecting your Cloud and On-Premise Apps and DBs in seconds, with no coding required.

This demo shows how you can use FoxWeave to add new subscribers to one of your Mailchimp mailing list whenever new users are added to your Zendesk account, all in under 60 seconds.

Of course you can perform many more integrations with FoxWeave.  Why not sign up for a free account and give it a try (or try without signing up).

We often get asked if FoxWeave can be used to put a HTTP interface in front of other services and databases.  Well the answer is yes, using the Webhook component.

There are loads of use cases where this makes sense e.g. putting a REST “like” interface on services/databases that don’t provide it themselves.  In this demo video we keep it really simple.  We use a Webhook to post data directly into a Salesforce.com account.  Of course Salesforce already has a web interface, but where this example would get interesting is if you needed to transform or filter the data being sent to Salesforce.  We don’t show that in this demo (in the interests of keeping it simple), but it is easy to do with FoxWeave.

I attended the SAP Startup Forum yesterday.  It was a very interesting event focused on SAP HANA, which is SAP’s new “in-memory computing platform”.  I hadn’t heard much about SAP HANA before yesterday, but after seeing the presentations, it seems quite like Hadoop, but with more of a focus on providing a better solution for realtime big data analytics through an in-memory data grid.  I’m sure SAP would describe it differently, but this was how I took it.

Anyway, some great startups presented at the event, including FoxWeave.  Mic Fitzgerald of OnePage CRM (who also presented) took the following picture of me giving the FoxWeave pitch.

There are a number of reasons why a company would want to synchronize multiple instance of Salesforce.com:

1. After a merger/acquisition you may want to merge multiple salesforce instances into one.
2. You may wish to sync a staging/testing instance of Salesforce.com with a production instance i.e. replication.

In this demo, we show how to do replication with FoxWeave.  We have two instances of Salesforce.com (i.e. two Salesforce.com accounts – “Production” and “Staging”).  We replicate changes made in the Production instance, back into the Staging instance.  Specifically, we replicate Account and Contact objects, but you can use the same methods to replicate any of the Salesforce objects.

We complicate the demo slightly however, by making sure that when the Contact objects are replicated to the Staging instance, they are linked to the same Account object as they were linked to on the Production system. So if, for example, an Account for “Acme.com” is added to the Production system and a Contact named “John Doe” is added to the “Acme.com” Account, when the two objects (Account and Contact) for “Acme.com” and “John Doe” are replicated to the Staging system, “John Doe” will be linked/connected to “Acme.com” on the Staging system i.e. the relationship betwen the two objects is maintained.

Enjoy the video and don’t forget to SIGN UP FOR A FREE ACCOUNT…

There are quite a few services out there charging for web forms data capture with email acknowledgement (capturing subscriptions etc). In this demo, we’ll show how FoxWeave can be used to create such a service in minutes, for free, and with no monthly form entry or email limits.  It uses Google Forms to capture the web form data entries and Google Mail for sending the acknowledgment emails, all wired together in minutes using FoxWeave.

Last week I blogged a demo showing how to use FoxWeave to migrate a customer list from an In-House MySQL Database to Salesforce.com (as Accounts).  In this blog we’re going to show another migration, this time migrating the same customer list from an In-House PostgresSQL Database to a Cloudant Database (a cloud-based NoSQL document database).

We complicated the demo slightly by having a hierarchical document structure in Cloudant i.e. the document is not flat in nature (as with the records in the Postgres DB).  We show how trivial it is to work with this type of structural mismatch between the source and target systems, to create document structures of any kind.

Please remember that this is an example of how FoxWeave can be used to help migrate existing/legacy data to a cloud service (or vice versa if you wish) and that FoxWeave can also be used to help keep cloud and in-house apps and databases in sync on a day to day basis i.e it’s not “just” a migration or “just” a day-to-day sync tool… it’s both !!  FoxWeave helps you move your systems to the Cloud (one of the biggest obstacles to cloud adoption), and then helps you
keep them all in sync after you get them there.

Enjoy the demo and please dont forget to SIGN UP FOR A FREE ACCOUNT …

(See the On-Premise App Deployment Guide for details of configuring the On-Premise App Deployer)

On Tuesday, CloudBees announced the addition of six new Services to their Partner Ecosystem.  These are the first “Verified Solution” partners to be added to the CloudBees ecosystem, and we are very proud to announce that FoxWeave is one of those services, along with CloudMine, HP ALI, Librato Metrics, Logentries and Postgres Plus Cloud Database.

An example of how FoxWeave lets you run user Integration Apps on CloudBees can be seen here, Sync’ing Wufoo Form entries to Salesforce.com.  To use CloudBees on your FoxWeave account, see the CloudBees PaaS Integration Guide.

This is great news for FoxWeave and FoxWeave users.  It is a real testament to the progress FoxWeave has made in a short period of time.

Benefits of PaaS deployment to FoxWeave/CloudBees users

So while our original reasons for choosing a PaaS deployment model were technical (explained later), it turns out that it also provides some real benefits to FoxWeave/CloudBees users.

Security:  Using the PaaS deployment model means you are not exposing your business data to your Integration Provider (i.e. FoxWeave).  By using the PaaS deployment model, you get the benefits of Cloud deployment (no in-house hardware, scalability, remote monitoring  etc), but without the security risks.  This is especially relevant if you are using services such as CloudBees AnyCloud.  With CloudBees AnyCloud on your CloudBees account, you can design your integrations on FoxWeave, but run them on HP Cloud Service, Amazon etc (via CloudBees).

Scalability:  Running a user Integration App on FoxWeave means running it in a shared, multi-tenant environment.  Your Integration App is running alongside someone elses.  Using the PaaS deployment model means you can run an Integration App in isolation and so scale it in isolation.  This benefit also applies to the In-House deployment model.

Extensibility:  Another benefit is for those that wish to develop and use their own FoxWeave Connectors. Anyone with a FoxWeave account can develop and install their own FoxWeave connectors on their FoxWeave account. For security reasons however, it is not permitted to use these connectors on FoxWeave Infrastructure, but you can run them on your own PaaS account. See Restrictions.  This benefit also applies to the In-House deployment model.

Technical reasons we have a PaaS deployment model

When we started building FoxWeave, we obviously wanted to find a way of delivering integration as quickly as possible.  Managing and scaling the backend FoxWeave services was one thing, but managing and scaling user integration apps was another thing.  Determining the demands of different user Integration Apps was going to be very difficult and one thing we did not want to happen was for one user Integration App to bring down the whole FoxWeave service.   The safest option seemed to involve running all user Integration Apps in isolation from the core FoxWeave services (console, datastore etc).  We could have built our own isolated app hosting (which we have done since then), but that was going to take too long.  This was when the PaaS option entered the mix.  Allow users to provide account details for their PaaS account and then run their integration apps out there, safely away from the core FoxWeave services and in an environment that was scalable on an app-to-app basis.

Why did we chose the CloudBees PaaS?

So that was the background to the original reason for choosing the PaaS deployment option, but why did we chose CloudBees?  We wanted to find the “easiest way” to deploy a JEE web application (containing a FoxWeave integration process) to a PaaS and CloudBees was the “easiest way” we could find.  With CloudBees, we could assemble a WAR file and fire it over to CloudBees through their easy-to-use SDK.  No messing around with git repositories, which for some other PaaS offerings is the only deployment model (CloudBees supports git too, but it’s not the only option).  We will be able to support other PaaS providers in the future, but CloudBees was first simply because they made it easier for us.

Put another way, CloudBees “got” something that other PaaS providers didn’t seem to get, and that was that sometimes people just want to use a PaaS to run apps.  Having support for the full app development lifecycle is great and cool, but it’s not always needed and so shouldn’t become something that needs to be worked around.

Keeping data in sync on a day-to-day basis across cloud services (XaaS), and between cloud and on-premise datastores is obviously one of the key benefits of FoxWeave.  This is very useful on its own, but for many companies there’s another major headache to be cured before day-to-day synchronization becomes an issue.

Before most companies can start using cloud based services (CRM, ERP etc), they first need to load those services with existing data that’s often stored in on-premise databases e.g. Accounts, Contacts, Opportunities etc.  In this blog, we demo how FoxWeave can be used to cure this headache.  We show how to load Salesforce.com with Accounts from an on-premise/in-house MySQL database.  Of course, the database could be a different type of database (Oracle etc) and the target cloud service could be some other CRM service (OnePage CRM etc), so for that reason we will follow up this blog with other examples of “moving data to the cloud“.  As you can imagine, this same basic concept can be extended to moving/migrating your data between cloud services e.g. when switching service provider to get a better deal or service.

(See the On-Premise App Deployment Guide for details of configuring the On-Premise App Deployer)