Goya Blog

FileMaker integration with Nextcloud

This integration was a request from a sponsor, who uses Nextcloud in a similar way to the Dropbox API example we posted recently.

Nextcloud

I didn't know much about the Nextcloud API and despite the documentation being somehow fragmented, the interaction seemed possible using the BaseElements plugin.

The idea is the same: we want to share a folder or file in Nextcloud from within a FileMaker solution.

Nextcloud has more than one API (with different implementations) and for our project we'll need 3 different services:

the implementation of these web services are quite different from the ones we covered in the previous posts (Dropbox, Zendesk and Mailchimp).

First of all the format used for the response is not JSON but XML and in the case of the webDAV API we have to define a cURL option to retrieve the field list.

If you're not familiar with cURL, it is a library used to transfer data using various protocols and it is used in the HTTP functions in the BaseElements plugin.

Authentication

The Nextcloud API provides only Basic Auth without any API keys or Token. We simply pass our username and password with the request:

https://user:password@demo.nextcloud.com/mydemo

Get the Files and Folders List

The first step in the process is to retrieve the list of files and folders hosted in our account. For this we'll use the webDAV API.

The docs indicate that we need to perform a PROFIND request: to do the we need to set a cURL option before calling our GET request.

The option to set is called CURLOPT_CUSTOMREQUEST and we have to set it to the value PROPFIND. The BaseElements plugin function to do this is

BE_Curl_Set_Option ( "CURLOPT_CUSTOMREQUEST" ; "PROPFIND" )

one thing to remember is that the effects of BE_Curl_Set_Option don't reset after a call. We need to explicitly reset it calling the function without parameters when we don't need the option anymore.

Once the cURL option is set we can perform our GET request. The url will be our base URL followed by /remote.php/dav/files/USERNAME/. If our username is admin and our domain is goyafm the url will be

https://admin:password@demo.nextcloud.com/goyafm/remote.php/dav/files/USERNAME/

or if we want to get the list from a subfolder instead than from the root

https://admin:password@demo.nextcloud.com/goyafm/remote.php/dav/files/USERNAME/THESUBFOLDER.

We will perform the call using the BE_HTTP_GET function

BE_HTTP_GET ( "https://admin:password@demo.nextcloud.com/goyafm/remote.php/dav/files/USERNAME/" )

The result is in XML and can be parsed using the functions BE_XPath and BE_XPathAll from the plugin.

Get the Users List

To decide who we are sharing our files with we need a way to identify them in the request, so our second step is to retrieve the list of users from the Nextcloud installation.

The Provision API uses a normal HTTP GET request to return an XML message. The HTTP Header OCS-APIRequest needs to be set to "true" and we can use BE_HTTP_Set_Custom_Header to set it

BE_HTTP_Set_Custom_Header ( "OCS-APIRequest" ; "true" ).

The url of the GET request will be our base URL followed by /ocs/v1.php/cloud/users which using the same example values becomes

BE_HTTP_GET ( "https://admin:password@demo.nextcloud.com/goyafm/ocs/v1.php/cloud/users" ) which for the users in this screenshot

Users_Nextcloud.png

will return

<ocs>
    <meta>
        <statuscode>100</statuscode>
        <status>ok</status>
    </meta>
    <data>
        <users>
            <element>admin</element>
            <element>nick</element>
            <element>salvatore</element>
        </users>
    </data>
</ocs>

Share

Now we have the folder we want to share and the user identification. We can use the Share API to send a POST request to Nextcloud.

If you have used Dropbox, Box or similar in the past the terminology used in Nextcloud can be a bit confusing: every time we share a file or folder we create a new "share", which doesn't mean we are creating a new folder.

So to create a new share we can use the endpoint /ocs/v1.php/apps/files_sharing/api/v1/shares passing 3 parameters:

  • the path of the file to share
  • the share type (0 = user; 1 = group; 3 = public link; 6 = federated cloud share)
  • the user with which the file should be shared.

These parameters are passed as the body of the POST request. If we want to share the folder Photos with the user salvatore the body will be

path=/Photos/&shareType=0&&shareWith=salvatore

so the complete request using BE_HTTP_POST will be

BE_HTTP_POST ( "https://admin:password@demo.nextcloud.com/goyafm/ocs/v1.php/apps/files_sharing/api/v1/shares" ; "path=/Photos/&shareType=0&&shareWith=salvatore" )

If BE_HTTP_Response_Code returns 200, we know the share was created.

Conclusion

This API was certainly different from the ones we covered in the past and it gave us a way of looking at different functions and different implementations.

A full example file has been added to the shared folder for our sponsors.

If any other subscriber has a request for an API integration, send us your idea!


Salvatore is our web services and integration expert, passionate about linking any API useful to our clients (or us!) to FileMaker. He loves to share ideas and a good story, and as a speaker at DevCon he manages to do both.


Goya Custom App showcased in FileMaker Webinar

Goya was recently approached by Endeavour Veterinary to build a solution to help them with improving some aspects of field data collection for their business. Endeavour Veterinary Ecology P/L is an Australian company based in Toorbul, Queensland, that provides specialised ecological, veterinary and wildlife management services.

They've got an ongoing project to preserve the wild koala population in Australia. This involves lots of time out in the field, tracking counting and measure koala numbers and all aspects of population health. With work like that, you need to have a way to track data locally without internet access, and bring it back into the office once you have a network connection.

Goya built a FileMaker custom app for their iPads that lets them do all their data entry in the field, and sync back to the office when required.

Offline sync is a great option for remote data management : it means you can do data entry anywhere, and push data to a central database when your network and workload permits. Having a purely local and non-web based solution on the iPad is the easiest and fastest way to get this sort of work done. And FileMaker Go makes it a really cost effective option compared to native iOS app development.

FileMaker recently showcased this solution in their ongoing webinar series on Increasing Productivity in the Field. You can sign up and view the webinar content to get more of an idea about the solution and the benefits of a custom iPad FileMaker app.

http://info2.filemaker.com/APACGoya080322017Webinar_reg.html

And if you'd like a custom iPad app to manage your business field operations, contact us for more information.

FileMaker integration with Mailchimp

Back for a new episode on FileMaker Integration with Web Services!

In the past three weeks we looked at what we need to integrate FileMaker with external APIs, and the code implementations for the Dropbox API and the Zendesk API.

Mailchimp

The idea for this series came while we were working on automating the process for our sponsorship program through FileMaker.

When someone signs up, we share a Dropbox folder with them (via web services), add them to our Zendesk support channel (via web services!) and then add them to our Mailchimp mailing lists, so that they can be notified when we release something new or we send out Beta updates. Having different Mailchimp lists for the different products, we want to add new members to the right one.

So this week we'll look at this last step and the use of the Mailchimp API from a FileMaker file. Similarly to what we did for Dropbox and Zendesk, we use the BaseElements plugin to do HTTP calls inside a FileMaker script.

Looking at the Mailchimp API documentation we'll see that every request type is defined by the HTTP method (GET, POST, PUT, DELETE, PATCH), the resource we want to work on (the endpoint) and the parameters of our request (the body). Let's explain this with an example:

the two actions we want to perform from FileMaker are

  • retrieve the information about the various Mailchimp Lists
  • add a new member to the list we specify

The documentation for the first action tells us we will GET (HTTP method) the list of Lists sending a request to the /lists endpoint. No body parameters are needed.

For the second action we will need to POST our request to the /lists/{list_id}/members endpoint. In the body we'll need to say what email we want to add and what status we want to assign to the new member.

The endpoints are relative to the base URL of the API, which for Mailchimp is

https://<dc>.api.mailchimp.com/3.0

The <dc> part identifies the data center for our account (more on this in a minute).

Mailchimp needs to know our system is authorised to interact with the account, otherwise everyone could change our Lists.

Authentication

The easiest way is to use HTTP Basic Auth creating an API key. The generated key can be used as the password for our requests.
Mailchimp doesn't care about the username so any string will do.

The last part of the API key identifies the data center. In the image below the dc is us-13.

zendeskAPI.png

Get the Mailchimp Lists

The first request is to retrieve all the Mailchimp lists. As explained before, we need to send a GET request to the https://<dc>.api.mailchimp.com/3.0/lists endpoint with no parameters.

We can use the BaseElements plugin function BE_HTTP_GET to call the API

BE_HTTP_GET ( "https://anystring:TOKEN@<dc>.api.mailchimp.com/3.0/lists" )

A successful JSON response from the API will contain nodes for each one of the Lists

{
    "lists": [
        {
            "id": "abc1234",
            "name": "the BE people",
            [...]
            "stats": {
                "member_count": 333,
                "unsubscribe_count": 0,
                "cleaned_count": 0,
                [...]
            },
            [...]
        },
        {
            "id": "xyz5678",
            "name": "the RESTfm people",
            [...]
            "stats": {
                "member_count": 222,
                "unsubscribe_count": 0,
                "cleaned_count": 0,
                [...]
            },
            [...]
        }  
    ],
    "total_items": 2
}

we can use the BE_JSONPath function to extract th information we need from the returned JSON:

BE_JSONPath ( $json ; "$.lists[0].name" ) will return "the BE people".

Add a new member to the list

In the Mailchimp API there are various ways to add a member to a list. The basic one is based on the /lists/{list_id}/members endpoint we talked about at the beginning of the article, while Batch Operations can be used to add multiple users at the same time.

A third method is to use a "create or update" function using the endpoint /lists/{list_id}/members/{subscriber_hash}.

We chose to use this method both for it's flexibility and because it let's us show a few details we didn't use when working on the other APIs.

The first thing to notice is that the HTTP method is PUT, which is the one normally associated with updating.

Looking at the endpoint we need to clarify what the {subscriber_hash} part means: the API expected an MD5 hash of the lowercase version of the email. It's a bit like a string identifying the email address.

To generate it we can use the BE_MessageDigest function from the BaseElements plugin:

BE_MessageDigest ( Lower("salvatore@goya.com.au"); BE_MessageDigestAlgorithm_MD5 ) will return B92A5EDE3BEDE58FEC9B0D473165475C (it's not a secret code!).

We know the method and now we know the url of our request, the last thing missing is the body. The only two mandatory fields are the email address and the status (if creating a new member), but it's always nice to also know the first and last name:

{
    "email_address": "email" , 
    "status_if_new": "subscribed", 
    "merge_fields": {
        "FNAME": "fname",
        "LNAME": "lname"
    }
}

Using BE_HTTP_PUT_DATA to send the request that becomes:

BE_HTTP_PUT_DATA ( "https://anystring:TOKEN@<dc>.api.mailchimp.com/3.0/lists/" & list_id & "/members/" & BE_MessageDigest ( Lower(email); BE_MessageDigestAlgorithm_MD5 ) ;
"{\"email_address\": \""& email &"\", \"status_if_new\":\"subscribed\", \"merge_fields\": {\"FNAME\": \"" & fname & "\",\"LNAME\": \"" & lname & "\"}}" )

A return code of HTTP 200 will mean everything went well and Mailchimp will send us back a unique ID for that member in Mailchimp.

Sample File

Once again, a complete example file is available to sponsors of the BaseElements plugin, along with previous examples for Dropbox and Zendesk.


Salvatore is our web services and integration expert, passionate about linking any API useful to our clients (or us!) to FileMaker. He loves to share ideas and a good story, and as a speaker at DevCon he manages to do both.


FileMaker integration with Zendesk

Second installment of our series on FileMaker integration with Web Services. Check the Intro and the first article about the Dropbox API if you've missed them.

Zendesk

This week we'll have a look at the Zendesk API. If you're new to Zendesk, it is a customer service software and support ticket system. At Goya we use it for all our support on both the BaseElements plugin and RESTfm.

When someone has a question or an inventive use for one of our products, they jump on Zendesk and create a ticket. Sometimes even the best developers need advice.

To allow that we need to add them to our support when they sign up for the sponsorship program. Doing it manually is repetitive and prone to error, and we are developers, so we've automated the process using the Zendesk API.

Like we do with Dropbox, we use the BaseElements plugin to do HTTP calls in a FileMaker script. If the terminology is new or you want to refresh your understanding of Web Services, the links in the Intro are a good starting pooint.

The requests we want to send to Zendesk are of two types:

  • retrieve the list of users already signed up
  • add a new user to the support system

To execute these requests we need to know what type of action they are (in HTTP terms the type of action is called "verb"), where we need to send them (the url or endpoint) and what parameters are necessary (body).

The first request translates to a HTTP GET verb (retrieving data) while the second one is a HTTP POST (send data).

The base url for the Zendesk API is

https://{subdomain}.zendesk.com/api/v2/

(ie https://baseelementsplugin.zendesk.com/api/v2/).

To test the code in this article and run the demo you will need a Zendesk subdomain, if you don't have one you can create a trial one.

Before actually calling them we need to authenticate ourselves to the API. Zendesk accepts both OAuth and Basic Authentication. An example of a Token in the headers was covered in the previous article about Dropbox so this time we'll use the basic username and password integration, but still using a Token to protect our real password.

Authentication

To generate a Token in the Zendesk API we need to go to the Settings page (only accessible to Agents or Owners of the channel):

https://{subdomain}.zendesk.com/agent/admin/api/settings

and enable the Token Access

zendeskAPI.png

Once we obtain a token, this is associated to the email address we use to log in to Zendesk and we will be able to pass them to the BaseElements plugin functions like this:

BE_HTTP_POST ( url ; body ; email & "/token" ; token )

Get the Users list

To retrieve all the existing users on our Zendesk channel, we can use the users.json,/code> endpoint. The full url will look like https://{subdomain}.zendesk.com/api/v2/users.json.

The request can be filtered to obtain only users with specific roles but in our case we want everyone, so the body of our request will be empty.

The following puts all the parts together (authentication, verb, endpoint, body) and uses the BaseElements plugin function BE_HTTP_GET to call the API:

BE_HTTP_GET ( "https://{subdomain}.zendesk.com/api/v2/users.json" ; "" ; email & "/token" ; token )

If our request is successful the response JSON will contain nodes for each one of the support users

{
    "users": [
        {
            "id": 1234567,
            "name": "Salvatore Colangelo",
            ...
        },
        {
            "id": 7654321,
            "name": "Nicholas Orr",
            ...
        }
    ]
}

To generate records in our database we can extract the data parsing the JSON using the function BE_JSONPath:

BE_JSONPath ( $json ; "$.users[0].name" ) applied to the JSON example above will return "Salvatore Colangelo".

Add a new user

Having a list that we can manage from FileMaker is useful, but our main goal is to add a new sponsor to the support system. The Zendesk API gives us a flexible endpoint that can be used both for creating a new user or to update an existing one

https://{subdomain}.zendesk.com//api/v2/users/create_or_update.json

This time we are sending data to Zendesk so we'll have to populate the body of our request. The parameters the API expect are the name of the new user, their email address and if necessary we can specify a role for the new user. If we don't specify one (our case) they will be assigned the end-user role.

The body of the request to add the user Nicholas Orr as an end user to the support is

{
    "user": 
        {
            "name": "Nicholas Orr", 
            "email": "nick@example.org"
        }
}

As said earlier this request is a HTTP POST so we'll use BE_HTTP_POST to send it

BE_HTTP_POST( https://{subdomain}.zendesk.com//api/v2/users/create_or_update.json ; {"user": {"name": "Nicholas Orr", "email": "nick@example.org"}} ; email & "/token" ; token )

So now Nick will be able to ask everything he wants to know about the plugin!

The Zendesk API can be used for tasks a lot more complex than this (we have clients creating tickets and updating them all from FileMakers) but the basics are the same explained in this article. Send us questions if you find an interesting endpoint you want to use.

Like last week, a complete example file (along with the Dropbox one) is available to sponsors of the BaseElements plugin, in the folder we share via the Dropbox API.

Now that we have shared the folder and linked the users to support, it's time to add them to our mailing list. Next week: FileMaker and Mailchimp.


Salvatore is our web services and integration expert, passionate about linking any API useful to our clients (or us!) to FileMaker. He loves to share ideas and a good story, and as a speaker at DevCon he manages to do both.


FileMaker integration with Dropbox

This is the first in our series on Web Services integration with FileMaker that I mentioned last week.

DropBox

The API we are going to look at today is DropBox. With this API a FileMaker solution can manage and share files, folders and Dropbox Paper documents.

As an example, when someone signs up to sponsor the BaseElements plugin, we share with a them a DropBox folder with every historical version of the plugin, as well as private beta versions with new functionality.

We do that with a FileMaker script that uses the BaseElements plugin to do HTTP calls to the Dropbox API. If you missed the first article of the series, it is an introduction to the world of web services and FileMaker.

Each interaction with the web service starts with a request from FileMaker sent to a specific url (or endpoint) along with the request parameters.

A request URL will look something like this:

https://api.dropboxapi.com/2/files/list_folder

This endpoint returns the contents of a folder.

The URL breaks down (reading backward) to: i want to use the list_folder function from the files category of the version 2 of the dropbox api. Makes sense? The first part will be the same in all our requests, the only parts that will change will be the function and the category.

Of course we also need to tell the Dropbox API what folder we are talking about and that is done through the parameters (or body) of the request, using JSON:

{
   "path": "/Goya/Secret_Projects"
}

One detail to remember about the Dropbox API is that it uses POST requests even for endpoints where we get data.

So the previous example called from FileMaker with the BaseElements plugin will be

BE_HTTP_POST ( "https://api.dropboxapi.com/2/files/list_folder" ; "{ \"path\": \"/Goya/Secret_Projects\"}" ; "" ; "")

If you go ahead and try that the API will send back an error (at least we know they answer!).

The request can't be processed because we haven't yet told the API what dropbox account we want to use.

So let's go back to our workflow for the Goya sponsors: we have an email address (we receive it from another API) and we want to share our folder with them.

Based on what we said, to successfully process the request Dropbox needs to know:

  • that we are authorized to interact with that Dropbox account
  • what folder do we want to share
  • who are we sharing the folder with and what privileges will they have on the folder and files

Authorization

To identify what Dropbox account we want to work on we need to tell the API that we are authorised to work on it. You do that by getting a token.

The token can be obtained going to this address https://www.dropbox.com/developers/apps and following the steps to register an app and create a token for that app.

Once we have a token, we can add an Authorization HTTP header to the request, and again we can do this with the BaseElements plugin :

BE_HTTP_Set_Custom_Header ( "Authorization" ; "Bearer " & Table::API Token )

Another header we want to add is the language we are using to send the body of our request. In our case it is JSON :

BE_HTTP_Set_Custom_Header ( "Content-Type" ; "application/json" )

Get the Folder list

We need to know the ID of the shared folder so that we can add our new sponsor to it.

The endpoint https://api.dropboxapi.com/2/sharing/list_folders returns a list of all the shared folders from the Dropbox account.

In the body we can specify a limit for the number of items returned.

The following call will return up to 1000 shared folders

BE_HTTP_POST ( "https://api.dropboxapi.com/2/sharing/list_folders" ; "{ \"limit\": 1000 }" )

The API will have one "entry" node for each shared folder

{
    "entries": [
        {
            "access_type": {
                ".tag": "editor"
            },
            "path_lower": "/secret projects",
            "name": "Secret Projects",
            "permissions": [

            ],
            "policy": {
                "member_policy": {
                    ".tag": "anyone"
                },
                "resolved_member_policy": {
                    ".tag": "anyone"
                },
                "acl_update_policy": {
                    ".tag": "editors"
                },
                "shared_link_policy": {
                    ".tag": "anyone"
                },
                "viewer_info_policy": {
                    ".tag": "enabled"
                }
            },
            "preview_url": "https://www.dropbox.com/somelink",
            "shared_folder_id": "123456789"
        },
        ...
    ]
}

We can parse the JSON using the function BE_JSONPath. So to grab the ID of the first shared folder we'll write

BE_JSONPath ( $json ; "$.entries[0].shared_folder_id" )

Share the folder

Now that we know the token, the shared folder id and the email we want to share with, we are ready for the last call to the API.

The endpoint to add a new member to a folder is, surprisingly, https://api.dropboxapi.com/2/sharing/add_folder_member.

The body of the request will look like this

{
    "shared_folder_id": "123456789",
    "members": [
        {
            "member": {
                ".tag": "email",
                "email": "salvatore@goya.com.au"
            },
            "access_level": {
                ".tag": "viewer"
            }
        }
    ],
    "quiet": false
}

where we specify the folder id, the email of the new member and what access privileges they will have.

Calling our BE_HTTP_POST with this url and body will add the member to the folder.

Success! This call doesn't return anything if successful, so we'll have to check the HTTP response header to know if everything went well.

If BE_HTTP_Response_Code returns 200, we know the email was added.

These are only two of the actions available through the Dropbox API and they were all we needed for this workflow.

A complete example file is available to sponsors of the BaseElements plugin, and is sitting in their DropBox share folder already.

Up next in the series, integrating FileMaker and Zendesk.


Salvatore is our web services and integration expert, passionate about linking any API useful to our clients (or us!) to FileMaker. He loves to share ideas and a good story, and as a speaker at DevCon he manages to do both.


FileMaker and web services (and us)

Like most modern companies, here at Goya we use web-based tools. Slack, Dropbox, Zendesk and Mailchimp are awesome platforms to organise our work and to share our ideas.

The best part though is that we can manage all these services from a FileMaker solution.

Which is exactly what happens when someone joins one of Goya's sponsor programs: their Dropbox, Zendesk and Mailchimp account details are auto created via FileMaker scripts.

GoyaSponsor.png

Pretty neat, it saves us quite a few clicks!

We are able to call the web services from FileMaker using the HTTP functions from the BaseElements plugin, and then parse the results using the JSON ones.

Want to try it yourself? In the coming weeks we will publish articles here and add examples to the share folder available to all our sponsors. If you'd like copies of our example files, please consider signing up as a sponsor.

Next week FileMaker integration with Dropbox.

In the meanwhile, if you're not sure this should matter to a FileMaker developer or what web services are, you can download the slides of my Devcon 2015 session
or check out this excellent introduction to web services from Mason Stenquist at DB Services.


Update : Part 1 is up : FileMaker integration with Dropbox


Salvatore is our web services and integration expert, passionate about linking any API useful to our clients (or us!) to FileMaker. He loves to share ideas and a good story, and as a speaker at DevCon he manages to do both.


BaseElements Update and more

It's been a while since the last BaseElements update, and I've had a few emails asking me what's going on. Rest assured we're still working on it, and things are progressing.

And FileMaker 15 is out today, and happens to coincide with me finishing up a big set of changes to BE, so an opportune time to post an update. So to answer all the big questions :

Are you still working on it?

Absolutely. We still use BE every day ourselves, and even use BE to develop BE and couldn't live with out it, much like a lot of you. We haven't sat still but development has been slower while we've worked on client work, RefreshFM updates, RESTfm updates and additions and bug fixes to the Plugin.

Why is importing objects so slow in b12?

What's mostly got us stuck is some changes to the Alerts that we introduced with the new 14 re-design. In order to better track the myriad of issues that can crop up, and be better able to handle errors, warnings, performance issues and unreferenced items, we've been consolidating them into a single alert. So we've added some extra items and included more detail for others, plus combined things into a single location.

And as every developer knows, when you add to a solution iteratively over a long period, all your changes add up. And what we ended up with was a solution for layout objects that was way too complex than it should be to get the job done. At some point in the last few betas our alerts auto enter calculation was doing a sum of a related field, which itself was un-stored, and that will never be fast.

You never set out to design a slow solution, and you never deliberately make a change that is going make things slow, but occasionally you add a great feature that has a cost you didn't plan for.

The solution was to go back and re-think the whole way alerts are generated across all the elements, but especially the large ones ( objects, steps, calculations ). And to do that meant putting a lot of these calculations into the XSLT so that the import was as simple as possible, and therefore as fast as possible.

If you want fast imports, remove all your unnecessary auto enters, lookups, stored calculations and indexes.

We've spent a lot of time re-factoring our XSLT to shift a lot of the complexity there instead of the import. This is a complex, difficult process - XSLT is handled differently in the plugin, vs the command line, vs the import, vs the debugger tools. This makes it really time consuming to debug and test any change.

Our base line for speed testing was importing our sample files ( BaseElements itself ) into the current BE 4. That takes about 5 minutes. We knew that the latest beta of 14 was slower, quite a bit slower. We needed to at least get back to where things were with that version.

At various times during the changes we had imports that took one minute, only to realised hardly any data had come in, and 7 minutes only to make a simple namespace change that cut that in half.

Finally we've got all our data, all working as we want and import times are ... drum roll ... 3 minutes. About a 40% savings on BE 4 and much faster than BE14b12. Excellent, not only did we fix the b12 issue, but we also improved on the previous version.

What's with the beta now that 15 is out?

Our plan with BE 14 was that we'd finish the beta late last year, and then release BE 15 on the release of FMP 15. Obviously that didn't go to plan.

We're fortunate that there are almost no changes to the DDR with 15 so our current release version of BE 4 will work with the FMPA 15 DDR just fine. So will the BE 14 beta.

So we're going to re-start the BE versioning at 15 and go back to b1 and pretend that the whole BE 14 beta never happened :) Well not quite, but it doesn't make sense to have BE 14 around with FMP 15.

There is no upgrade cost from BE 14 to 15. So we will now work on finishing up the remaining features we were working on ( reports mostly ) and release BE 15 as what we were going to do with 14. Everyone who has bought BE back since mid last year will get the final release of BE 15 at no charge and all the current BE 14 licences will work just fine with BE 15.

What else have you done?

One of the biggest support issues we have is in bad XML that FMPA generates that is invalid and so can't be imported. We are pre-processing a lot of that and removing some of these characters and so a lot of imports that would have failed in older versions will work in BE 15.

What else are you going to do?

We've still got some tweaks to how the UI works in BE 15 that we need to work on. There is the reports to do, and we've got some great ideas about those that we think are going to be awesome.

Thanks to everyone for your patience, and we hope it's not going to be much longer till the BE 15 final. In the mean time grab a copy, and send us any feedback.

BaseElements beta 3

We've posted a new version of the BaseElements 14 beta, the new download is b3. Although I was hoping to have a final release done by now, it's taken a bit longer than anticipated.

This version fixes the windows import issue that quite a few people saw, so I've put back the mac and win runtimes. There is a beta version of the plugin out for this.

Great new addition to this version is a new version of fmSearchResults. This is a beta release, with a heap of new functionality, so I'll post more about it soon, but it's good to have this back.

Hopefully this week will finish up some of the outstanding issues - reports, and some of the error notifications, and then we should be right to wind up the beta and start looking towards new functionality.

BaseElements Plugin Updated to 3.1 adds SMTP and more

And one more release note, we've updated the free BaseElements Plugin to 3.1.0. This is a huge release, lots of cool new features.

This version removes support for Windows XP, so be aware of that if you're running older OS versions.

But in return you get SMTP along with JPEG compression for reducing container picture sizes. There's a ConvertContainer for turning a file to a picture and vice versa, so no more exporting and re-importing. There's the ability to evaluate JavaScript inside the plugin, which opens a whole world of possibilities. And BE_ImportFile for importing files into containers - you can do this in the client, but now you can also do it on the server via the plugin.

The documentation will be updated in the next few days, I'll post another note here when it's done.

Sponsors

Thanks again to all the people and companies that sponsor the plugin. It's because of their support that you get all this for free, so if you use the plugin and know someone who sponsors, make sure to buy them a round.

And if you can, please consider sponsoring. It doesn't cover all our costs, but it does help, and you get a proper support channel and a bunch of other cool plugin related code.

New Functions

  • BE_ContainerIsCompressed
  • BE_ConvertContainer
  • BE_Curl_Trace
  • BE_EvaluateJavaScript
  • BE_Gzip
  • BE_ImportFile
  • BE_JPEG_Recompress
  • BE_SMTP_Send
  • BE_SMTP_Server
  • BE_UnGzip
  • BE_Values_ContainsDuplicates
  • BE_Xero_GenerateKeys

Other Changes

  • BE_Curl_Set_Option: label function parameters as optional
  • BE_Curl_Set_Option: the options CURLOPT_HTTPAUTH & CURLOPT_PROXYAUTH take named constants
  • BE_HMAC: add a parameter to allow and input encoding for Base64 and Hex
  • BE_HTTP_POST: allow post args to specify file paths using the @ syntax
  • BE_HTTP_POST: do not crash when a http post contains a parameter that is not a key=value pair
  • BE_JSON_Encode: correctly handle leading 0 for real numbers
  • BE_Values_Unique, BE_Values_FilterOut: add option to be case insensitive
  • Ensure that Get ( InstalledFMPlugins ) returns the same value on both OS X and Windows
  • Remove support for Windows XP

BaseElements 14 beta now available

BaseElements has grown up so quickly it's skipped 9 whole version numbers. Straight from version 4 to version 14, in order to better keep track of compatibility with the current release of FileMaker Pro.

We have a beta version available :

http://www.goya.com.au/files/baseelements/14.0.0b1/BaseElements14_Mac_Runtime.zip
http://www.goya.com.au/files/baseelements/14.0.0b1/BaseElements_14.zip

I started talking about the design of BaseElements in an earlier blog post, and I'll have a lot more to say on that, including a followup about our reasons for making the changes we have.

But for now I wanted to get this beta out so people at DevCon can have a play and see for themselves.

Upgrades

This is a paid upgrade, you can purchase a discounted upgrade during DevCon but the discounts won't last, so get in quick.

Syndicate content