When we show how easy it is to add web services to your FileMaker Solutions people always say – WOW, That's cool! We have taken the time to make it as easy as possible. If you can write FileMaker calculations, you can interact with Web Services – yes it really is that easy.
Version 3.5 has significant changes:
- We have added REST support so you can integrate to any REST based service.
- XPATH is built right into the product that means that getting a list of results is extremely powerful. No loops to write - just a simple XPATH statement and presto a list of results from any xml result. Say goodbye to complex text parsing calculation and welcome to the power of XPATH.
- Another time saving feather is the ability to load the WSDL from a url. This allows you to work seamlessly from client once you have hosted your file on server.
- Encode and Decode Base64 - if you need to send your service provider a file or maybe they custom generated an image or pdf that you would like to download, then this feature will allow you to do just that.
- Load Web Services directly from URL
- Separate 'preferences' for each Web Service (timeouts, etc.)
Version 3.5 is a very exciting release because there are more and more WSDLs that we are able to parse and have been working closely with the open-source project to enhance and extend it.
Another very exciting opportunity in the FileMaker community is that 360Works recently announced the release of Web Services Manager. What this tool allows you to do is to expose your FileMaker scripts as WSDL functions. Combine the ability that 360Works provides in being able to publish your FileMaker scripts as Web Services, and our plug-in which lets you harvest those functions and interact with that particular web service and now you have opportunities to build light weight, non-persistent connections.
Dynamically loading functions is very cool, but the fact that a simple calculation can be getting results from Google, getting a shipping rate from FedEx, or looking up statistics for a particular neighborhood is even more exciting. The possibilities you can offer your customers are innumerable.
Before we dive into each of the functions, it is important to understand how to distinguish the default functions from the functions that you'll be using when you interact with a web service. If no WSDLs are loaded, the only functions that will show up are the default functions. We'll explore each one of these in detail in the default functions area.
Default functions. Note: default functions appear at the top of the list and are prefixed with an underscore.
_FmNx_GetPref( key )
_FmNx_Load_WSDL( wsdl_name; wsdl_document )
_FmNx_Register( license_key; owner )
_FmNx_Reload_All
_FmNx_SetPref( key=value[, key=value[, ...]] )
_FmNx_Unload( wsdl_name )
_FmNx_Version( short/long )

These functions perform various tasks. Register the plug-in, get the version, set preferences, get preferences, load WSDL functions, and unload WSDL functions. A good analogy might be to think of the Web Services Plug-in much like a car, and WSDLs like gas - so without gas you car can't go anywhere. In an analogous way, without any WSDLs, your database will not be interacting with any outside services.
Basically the publisher publishes the functions with which you can interact with their data. The function puts that information into an xml document called a “WSDL”. Because a WSDL can be dynamically loaded (as is the case with our plug-in), it can also be referred to as a self-describing API (application programmer interface). Our plug-in does the heavy lifting, reads the functions that are available in the WSDL, and exposes them as easy-to-use FileMaker external functions - accessed via the FileMaker calculation window.
So what does WSDL stand for?– “Web Services Description Language”.
Where can I find some WSDLs? Google: "Web Services"
TIP: Go to google.com and type “define: wsdl”. You’ll get a list of links from reputable sources that explain what a WSDL is. Here is one of them.
“WSDL or Web Services Description Language is an XML format for describing network services as a set of endpoints operating on messages containing either document-oriented or procedure-oriented information. The operations and messages are described abstractly, and then bound to a concrete network protocol and message format to define an endpoint”. - soaprpc.com
So any program that can read WSDL’s will be able to interpret the functions and know how to communicate with that service. For example there is a SOAP Client available for OS X (doesn't look like it continues to be supported). When you ask the plug-in to load the WSDL functions, be they from the WSDL folder or dynamically from a field, those WSDL functions are exposed to you as native FileMaker calculation functions. They will appear in the External functions list with the WSDL name followed by an underscore “_” then the function name which the plug-in managed to extract when it when it parsed the WSDL. For example, if you install the SMS WSDL from CDYNE then your list of available functions would look something like this.
SMS_GetSMSResponse
SMS_GetSMSStatus
SMS_SendMultipleSMSAdvanced
SMS_SendMultipleSMSBasic
SMS_SendSMSAdvanced
SMS_SendSMSBasic
TIP: If you download WSDLs that have really long names you might want to consider shortening the name so that you have more space to see related function names for that WSDL (seeing as the external functions window can't be re-sized).
IMPORTANT: If you program functions to rely on on the name you have chosen and later want to change the WSDL name for whatever reason, you'll have to go through your code to find every place that function was referenced. A suggestion might be to write a custom function, this way it is only one place that you'll need to change it.
Comments