Was there a previous version of the plugin that supports FileForce?
How does FileForce work?Yes. FileForce uses remote version of the Ruby plug-in which employs a different strategy for integrating Ruby with FileMaker. The remote version acts as a client to a Ruby evaluation server. This "remote" strategy works well in both FileMaker Pro and Server editions, and it eliminates the code duplication and synchronization problems that existed with the embedded version.
The embedded version includes a full Ruby interpreter inside a FileMaker plug-in and is not used in FileForce.
There are two main parts, the plug-in and the evaluation server. The plug-in acts as an Agent that receives chunks of Ruby code from FileMaker scripts, sends it to the server for evaluation, and returns the results it receives back. For now, the server and the plug-in both reside on the same machine, but the server can be anywhere and serve many simultaneous clients, each with its own private context.
There will be limits when dealing with very complex data relationships, just like it is in Salesforce itself. However, the
multi-layered design of the plug-in (C++/Ruby/FMP) allows for a lot of flexibility and offers various options to solving problems.
What technology is FileForce based upon?
We have a plug-in which employs different approaches to solving the similar problems. To date, w have modules that sit on top of the plug-in (FMAR, FileForce, and maybe others later). Each module tackles a different technology/platform and will have its own requirements and issues, but they all depend on the same plug-in.In the case of FileForce, there is a FileMaker Pro plug-in which communicates with a (Ruby) daemon on the organization's server. This server passes information to and from the Salesforce server(s). There are FileMaker-specific Ruby libraries which use FileMaker's various 'classes': database, table, fields, etc..
The term "sync" can mean many things and take many forms. FileMaker Pro makes it easy to tap into the core record actions (load, commit, revert) and this allows for pseudo-realtime syncing with Salesforce data.
All core objects and custom fields available in the Enterprise WSDL
(whose names end with __c) are read/write accessible.
Currently, in addition to the basic CRUD (Create/Read/Update/Delete)
functions, there are 3 additional functions:
It is easy to add more functions based on the above, like batch
- Fetch all object IDs for a specific object class (list)
- Fetch all object IDs for a related object class (one-to-many)
- Search for instances of a specific object class that match a given query
- Run an arbitrary relationship request (cross-object formulas, incomplete)
updating or deleting a set of objects that match some given criteria.
The Salesforce API has access to all objects defined in an installation (as
described by the Enterprise WSDL), including core objects, custom
objects, and any core and custom fields defined within them.
Communication with the Salesforce platform is carried out via SOAP
over HTTP, so the session management features are identical to those
of web browsers and other REST clients.
The security measures currently in place prevent clients
(plug-ins) from interfering with each other's sessions, by creating
isolated handlers for each. However, there are several things that can
and should be done to address the following:
- Preventing unauthorized plug-ins from connecting to the ruby server by adding a username/password for the connection between the plug-in and the ruby server
- Preventing traffic sniffing by adding support for SSL to encrypt all traffic, both between the plug-in and the server and the server and Salesforce (the latter is already in place)
As it is in Salesforce. the account used determines ownership and
access privileges. Currently only one Salesforce account is supported
per server installation. This is not on purpose or a limitation, it
just hasn't been dealt with yet. The ideal setup will be configurable
per plug-in instance (through the plug-in preferences dialog). When
implemented, every instance of the plug-in can act as a unique
Salesforce user, or share a single Salesforce account.
All errors are properly handled in Ruby when they are reported by
Salesforce. What remains is a way to report these to FMP in a way that
fits with and makes sense for that environment.
The syntax is similar to the Salesforce syntax for cross object
formulas. For example, "oppurtunity.contact.account.website" will
return the website URL for the account associated with the contact for
the opportunity.
Rapid. Once the function become available in the WSDL, they only need
to be wrapped with 3 to 4 lines of code to make them available to the
plug-in. This is one of the biggest advantages to using Ruby.
Undetermined at this time. It is a matter of developer availability.
Yes. The ruby server can be bound to a single interface card, or all
(any) interface cards on a machine. For selective binding, multiple
instance of the server can be launched, each bound to a specific
interface and port.
Not at this time.
If it's about the amount of network traffic generated, then it is akin to
that generated by accessing Salesforce via a web browser. It is
actually lower due to the fact that it does not download all the
images, CSS and JavaScript associated with web pages.
We're sure this can be done since it's available in the WSDL, but
the details need investigation. We have not tested this as of 05/25/2010.
ETL stands for Extract, Transform, Load. We designed the plug-in to fill this primary goal, not to become a complete Salesforce "clone" in FileMaker Pro. That is why many of the features above have not been addressed as of 05/25/2010.
There will be limits when dealing with very complex data
relationships, just like it is in Salesforce itself. However, the
multi-layered design of the plug-in (C++/Ruby/FMP) allows for a lot of
flexibility and offers various options to solving problems.
You can send email to sales@beezwax.net and ask to be put on the FMP/Salesforce product mailing list. We will notify you of updates, specials, WebEx demos, training opportunities and all else related to this innovative product.
Comments