1-more-thing

Author: Fabrice Nordmann

  • Client Side Virtual List

    Client Side Virtual List

    [vc_row bg_color=””][vc_column][vc_column_text]Last June at dotfmp 2018 in Berlin, we had the great honnor to welcome an esteemed Californian member of the FileMaker developer community, Kevin Frank (@FileMakerHacks)

    Besides being a long time friend -I remember the old times when participating in our ‘Friday Night Chat’ at 3AM CET wasn’t an issue for my young, fast-recovering body- he’s always been and still is one of the most talented and clever writers on the topic of FileMaker. I love (I somehow share, I hope) his kind of scientific approach to FileMaker, and his blog FileMaker Hacks is an endless source of information and inspiration.

    At dotfmp, he presented two sessions in a row about virtual lists. I’m not going to repeat everything he said there because some of it is available on FileMaker Hacks already, and I wouldn’t pretend here to be able to fill the gap between what can be read there and what you perceive while listening to someone in person.

    But the magic at dotfmp is that it is an unconference. And the schedule evolves all the time, so a session can be extended in another, or a discussion can be scheduled almost on the spot and everyone notified, thanks to the great web tools Egbert Friedrich (@dotfmp) and Andries Heylen (@AndriesHeylen) have put together.

    Kevin’s virtual list sessions made me think I should show something on the subject, so Laurent Spielmann (@laurent_at_joes) and I pushed a new session to the calendar, and here it goes (thanks to Heidi, room moderator and keeper of the keys 😉 )

    Laurent and I have spent a large part of our time during the two last years working on a big project. The application manages tens of gigabytes, super intensive activity (24/7, 120 users), constant imports from various data sources, 4 servers, 40 files… a beast.

    Why a virtual list?

    InterfaceTo make a long story short, the application is about booking management and all the customer support that goes with it.

    In the main interface used by the greater part of users, there’s a portal showing all the interactions with the customers, providers…

    There is a lot of different things in there: incoming and outgoing e-mail, sms, notes, internal messages… a lot. Each is also displaying data more that 1 table occurrence away (user, department…)

    Because FileMaker portals (and list views) can only represent records, as opposed to a result of a query on various tables (union), we would usually tend to denormalize data and store all these different things in the same table. But with such an amount of data, this would be unimaginable. Not only is the data split accross multiple tables, but also accross multiple files.

    As a result, a virtual list is a good option for the UI.

     

    Previous situation

    In fact, the solution we had designed in the first place was not really a virtual list. It was a somehow-but-not-really-virtual list. For each record in one of the data tables, we would create a record with a minimal amount of data in a UI table. Basically, it contained the booking ID (booking being the main record from which we need to see the related data), and the UID of the related record.

    All the rest (displayed data, tooltips, data used in conditional formatting…) was obtained using unstored calculations. So a record of our interface table could display information coming from an inconming e-mail, an outgoing sms and so on.

    So in a way, this list was virtual because the data it displayed was not stored in its table but using unstored calculations. But on the other side it wasn’t virtual because the records really existed. A booking record had n related records in the view table.

    After a year and a half of production, this almost empty table was about 13 gigabytes (most of which was index). We had to do something.

    previous situation

    Why not a really virtual list?

    At this point, you might wonder why we hadn’t chosen a truly virtual list.

    There are two reasons that combine.

    1. avoid data transfert over the network. An approach of the virtual list is to get all the required data in one or more global fields, and then parse it in different fields or repetitions using unstored calculations. In this application, it is common to load a record of which you see only a few related records, without scrolling to see all related data. Therefore there is no need to download all the data into a global field. With 120 users on the network, downloading so much unnecessary data would have been a problem. So we knew that even if we would go for a virtual list (every user would look at the same records, but each record would display something different, depending on which booking is loaded), the data would have to be unstored and related (i.e. data for an incoming e-mail would still reside in the incoming e-mail table)
    2. given 1, the number of users also has an impact on the unstored calculations. If 120 users are looking at the same records (but viewing different related data), experience tells us an application becomes sluggish. This would not be the case if the data was not related but entirely in the virtual list. But as explained above, it was not possible in our case.

    And suddenly came… FileMaker 16

    Just when we needed to tackle this file size issue, FileMaker 16 was released. And with it the solution to our problem.

    The feature that helped us is the ability to define an External FileMaker Data Source as a variable. To me, it’s the most important change in recent years. It widens the horizon tremendously, with all sorts of uses and contexts.

    In this instance, we used it to eliminate the ‘too many users issue’ by loading the virtual list on each client.

    Here are the steps that we took:

    Change in the data model

    This steps doesn’t apply to most situations. It was necessary in ours, but I could write another blog post just on it.

    In the previous situation we had millions of records with basically foreign keys (one for the booking, one for each source of related data). The rest was all unstored calculated fields.

    We wanted to get rid of them and have only one record per booking with all the required information. We could even have added this to the booking table, but the plan was NOT to make this table heavier (and there are plenty of other reasons why we wouldn’t do that, but they’re off topic).

    So we went for a CLOB-like approach. In our new table, we had of course the booking ID (foreign key), and another text field in which we needed to store everything we need for the virtual list.

    So say that each row of our portal had a id_user, potentially some keys among: id_provider, id_customer, id_incomingEmail, id_outgoingEmail, id_incomingSMS…

    We defined a format, using pipe as separator “|” for fields (which makes it a not-a-CLOB, one could argue), and ¶ for records.

    So for 1 booking we could have


    |user345|||outSMS||
    ||||inEmail2048|||
    …

    and so on. So each row of the future portal would have to look up to 1 line only.

    This is off topic, but once we agreed on the format, we wrote a script to transform our existing data into this new.

    The first time we ran it and measured performance, we concluded that a fast computer would need about 9 months to process all.

    So we tried to optimise. The time fell to 4 months. Better. Not good enough. We were not in an emergency, but I can’t let a computer working for 4 months just to transform some data. No way. No, no, no.

    Then I asked the community. What language would you use to do this? I had the intuition that Python was a good option. Indeed, several people suggested it to me. That was reassuring.

    But two developers that I value immensely, David Wikstrom (@CamelCasedata) and Clément Hoffmann raised their hands and said “R”.

    David wrote a small application in R, and it took exactly 8 minutes to do the job FileMaker was doing in 4 months. So just to say: never let the system beat you. There’s always a way.

    So now instead of having between 1 and 250 records for each booking in the old view table, we have exactly one.

    Of course, this change in the data model had immediate impact: we also needed to modify the processes that used to create/edit/delete records. Now it should only work in this single record (add a line, remove a line, edit a line). But this was quite trivial.

    New situation

    The Local File

    Thank you for reading this all the way, but so far there is really nothing about a ‘Client Side Virtual List’, and this blog entry looks more and more like some link bait.

    Don’t worry, here it comes.

    We created a new file that was to be open (hidden) by the client. It has references to all hosted files it needs to get its data from or resolve unstored calculations. The external references point to the server with an absolute path. (fmnet:/<server>/<filename>)

    As the file will not contain any other data than IDs, we went for a very straight forward security policy with a auto-login defined in the file options.

    The file (Localfile.fmp12), with no data at all was then inserted in a container of the Settings table (a single record table) of the main file.

    Since FileMaker 16, you can define a FileMaker External Data Source using a variable, meaning that each user for instance can have his own source.

    So we defined in the main file (the one with the portal), a variable data source pointing to the client temporary folder, followed by the local file name.

    Note: you need to do this before any call to that datasource is made, even implicitely. Namely, it means that not only should you declare this variable in your startup script, but also you can’t have any reference to the external source in the startup script, because at runtime, FileMaker will resolve all external references when the script begins. Any call to this external source should happen in a subscript.

    Startup script

    1. Startup script begins
    2. A variable is declared: Set Variable [ $$localPath ; Get ( TemporaryPath ) & “Localfile.fmp12”]
    3. Perform script [ Install local file ]
    4. Do other things without any reference to the local file, otherwise the existence of the other file will be resolved in 1. With no chance to declare a variable (2.), and therefore leading to a ‘file missing’ situation.

    Subscript (Install local file)

    1. Go to layout [ Settings ]
    2. Export Field Contents [ containerField ; $$localPath ] // the container field contains the client side file.

    That’s it! Now all we have to do is to load the virtual list. For this we use a simple lookup.

    Then a loop creates as many records as we need to display. And we can delete them on next run (remember it runs locally, there is no impact on other users because they’re working on their own file). The load script is triggered onRecordLoad on the main file.

    An optimisation we made was to split the virtual list into several (1 per ‘column’) before we create the records. This made the system even faster.[/vc_column_text][/vc_column][/vc_row][vc_row color=”color7″ text_color=”color4″ global_atts=”yes” style=”padding-x: 5px; padding-top: 25px; align: center; ” bg_color=””][vc_column width=”1/4″][ish_icon icon=”icon-download” align=”center”][/vc_column][vc_column width=”3/4″][vc_column_text global_atts=”yes” css_class=”btn btn-primary”]Download a sample file here. ClientSideVirtualList.zip

    Please share if you liked this post.[/vc_column_text][/vc_column][/vc_row][vc_row bg_color=””][vc_column width=”1/1″][vc_row_inner][vc_column_inner width=”1/1″][/vc_column_inner][/vc_row_inner][/vc_column][/vc_row]

  • dotfmp Developer Challenge

    dotfmp Developer Challenge

    At recent dotfmp conference in Berlin (did I already mention this is the best FileMaker conference I know?), a developer challenge was orgnised.

    The challenge was to find the fastest way to download data from a FileMaker hosted database to a FileMaker Pro Client over the network.

    The table had 50K records (10 fields) of which only 10K had to be downloaded.

    But the important thing was that data, once on the client, had to be in any structured, workable, searchable form, not necessarily records/fields.

    @AndriesHeylen and I came up with a solution that I believe was considered interesting by the audience, so I’ll share it here, not to say that this is the best way or that I would necessarily use it in production, but I think it’s valid and it’s a good opportunity to visit some nice tricks.

    I’ll write this post in a kind of story-telling style, because I think the path we followed was as interesting as the solution, if not more.

    To rephrase the challenge, here is what needed to be done:

    1. select 10 000 records among 50 000 (any would do)
    2. transform the data stored in a table into something more appropriate for the next steps
    3. make the data transit over the network from the server to the client
    4. ‘render’ this data as a structured array, if that was not already the case, depending on what we would do during step 2.

    For each of this tasks we had many options in front of us. So because we hadn’t the time to explore them all (oh yes, I forgot to mention that we had approximately 45 minutes to solve this… while eating in a nice Vietnamese restaurant on Kastanienallee)

    So our first approach was to brainstorm about each step independently, so we would only see later how our favorite (supposedly fastest) techniques would combine nicely.

    Before we begin, let’s mention that there was one ‘obvious’ solution that was doing the whole thing: declaring a variable on the client, using ExecuteSQL function.
    ExecuteSQL ( "SELECT * FROM Datset FETCH FIRST 10000 ROWS ONLY" ; "#F#" ; "#R#" )
    Where #F# is a custom field separator and #R# a record separator.
    We didn’t follow that path because… there was no fun, and we still had 44 minutes to go.

    For step 1, selecting the records, we thought about 2 different ways:

    • through the found set
    • through a query

    A SQL query could be used in the context of an ODBC import (Import records from ODBC), but there’s a no go for this: the only output of Import records is… creating/updating records. We knew that this would take too long, so this ‘easy to solve’ first step showed us immediately that our strategy was not perfect.

    Before we could brainstorm on each step independently, we needed to exlude ways that we knew for sure would slow down the process.

    We identified 3 potential bottlenecks that we wanted to avoid

    • A – pre-formatting the data on the server using unstored calculation. Even with a simple calc this would be expensive, and it would make the solution not scalabale.
    • B – parsing data on the client, including creating records: data had to be ready to use or should not need more than a global transformation, not a per record or per field one.
    • C – sending a long text string over the network: we assumed it would take longer than if the string was encapsulated in a file

    Given this, we browsed the 4 steps

    1 – Select the 10K records

    To select the 10K records we could only use the foundset since the SQL Query could happen only in Import Records, and we didn’t want to import records (B)
    So we would run a script like:
    Go to layout [ Data ]
    Show all records
    Go to record [ First ]
    Omit multiple [ 10000 ]
    Show omitted only

    2 – Export records

    To avoid A and C, we thought the best way was to Export records to a text file (CSV)

    This made it clear that the main process (including step 1) should be a server side script because the export would be much faster on the server.

    We chose CSV because we believe this is the fastest, but we knew there was a glitch there: the result would not be very easy to use because the flavor of CSV FileMaker uses for its exports, using comas, double quotes and separator for multiline contents is not easy to parse using FileMaker calculation functions (certainly doable, but not easy)

    So we thought that if we had time (there was still 25 minutes to go), we would use XML/XSLT instead. It wouldn’t make a big difference in terms of performance.

    3 – Make the data transit over the network

    What we know (or think we know, which are two different things) is that sending a long string as a script result would take long. So we wanted to return a text file instead (C). Now that I’m writing this post and that I have much more time, I wonder if we shouldn’t have simply returned the text file as a script result (script results, as script parameters or variables can be of type container). But while on a hurry we went for something different: we created a ‘transfers’ table with a container field and an indexed ID field (serial number)

    So after exporting (2) our process:

    • creates a new record in ‘transfers’
    • inserts the file into the container (using Insert from URL and the file protocol, because Insert File is not server compatible)
    • exits the server side script with the ID of the transfer record as a result (token)
    • the calling (client side) script gets the token using Get ( ScriptResult )
    • goes to the transfers layout
    • finds the transfer record

    I should mention that inserting a file using insert from URL ate a full 5 minute of our time, therefore ruining our hopes to order desert. This was due to a change in FileMaker 16 that we had forgotten: to convert the path to where we export the records to into a URL from which we can insert the file, we have to remove the system drive. But since version 16, Get ( SystemDrive ) returns empty on FileMaker Server on macOS, so we have to extract it from the Temporary Folder path.

    4 – Extract the data into a variable

    OK, so now the client has a text file. It’s stored in a container field of the current record, but it could have been available as a script result.

    What we now have to do is to read this text file and ‘extract’ its content into a string.

    To do this we simply use this not so simple calculation :

    Base64Decode ( Base64Encode ( transfers::file ))

    In fact we could also use simply TextDecode ( transfers::file ; "UTF-8" ), but it only occurred to me later on. And as a matter of fact, we had several questions about the former expression while presenting our solution, so I’ll try to give a bit of explanation.

    Base64 is a encoding algorithm that allows encoding any data. This is very much used to embed binary files in a text, like for example an image in a html e-mail when you don’t want the image visualisation to rely on an internet connection. It is not an encryption method, although a base 64 encoded text is not readable by a human being (that I know, that is to say).

    So basically Base64Encode and Base64Decode are two inverse functions, which means that

    Base64Decode ( Base64Encode ( "abc")) = "abc"

    But it’s not as easy as this and I’ll try to give a clearer explanation that the one I gave when I was asked in Berlin.

    In this process, a text can be in 3 different states:

    • 1⃣ a string (data of type text in FileMaker)
    • 2⃣ Base64 encoded text
    • 3⃣ encapsulated in a text file

    Base64Encode ( data ) converts a string or a file to a Base64 encoded text depending on the parameter it receives (1⃣➡2⃣ or 3⃣➡2⃣)
    Base64Decode ( text {; fileNameWithExtension } ) converts a Base64 encoded text to a string (2⃣➡1⃣) or to a file (2⃣➡3⃣) depending on whether you pass a filename or not.
    So the two functions are inverse, but on two different operations.

    base64 encode Decode diagram
    In our example, Base64Encode translates a file into Base64 (3⃣➡2⃣) and Base64Decode translates the base64 encoded string into a string (2⃣➡1⃣).

    But again, TextDecode (released with FileMaker 16) is the best option.

    That was it, we had 4 minutes left, so just the time to wrap all this in 2 scripts (client side and server side), and add some performance measurement using get ( CurrentTimeUTCMilliseconds ) while paying the restaurant bill, fold the mac and head to the conference room where the solution had to be presented.

    Running on a local machine (with FileMaker Server and Pro Advanced on the same computer), the whole process was taking 0.4 seconds. On a local network (WIFI, quite busy and unstable, it took between 0.6 and 0.8 seconds). Not bad.

    Please do not hesitate to share your ideas or leave a simple comment below.

    client side script

     

    server side script

     

    Download the FileMaker file here: dotFMPcdotFMPchallenge (Admin / 1234)

  • FileMaker Server 17 : conservez bien le certificat de licence

    FileMaker Server 17 : conservez bien le certificat de licence

    Parmi les changements liés aux nouvelles licences FileMaker, il y a une petite chose à laquelle vous devez faire attention.

    Si vous avez un contrat de licence annuel ou sous maintenance, vous avez déjà dû recevoir un e-mail de la part de FileMaker dont le sujet est :

    “Plateforme FileMaker 17 – Disponibilité de la version avec maintenance”

    Comme chaque année, il vous permet d’accéder aux liens de téléchargement de la nouvelle version pour une période de 30 jours, ainsi qu’à votre nouvelle clef de licence. (Celle-ci, c’est une nouveauté appréciable, ne devrait plus changer à l’avenir.)

    téléchargment Certificat De Licence

    Mais attention ! il y a une nouveauté à télécharger : le certificat de licence de FileMaker Server. Or si passé les 30 jours il est toujours possible de retrouver un installateur de FileMaker Pro Advanced ou FileMaker Server en téléchargeant une version démo, il n’est en revanche pas possible de retrouver ce certificat de licence, sinon bien sûr en appelant le service technique.

    Téléchargez-le et conservez-le donc bien !

    Pour rappel, si vous passez par notre intermédiaire pour acheter/louer vos licences, vous bénéficiez d’un service de récupération rapide de votre clef de licence*… à condition de nous informer de celle-ci. N’oubliez donc pas de nous communiquer votre nouvelle clef.

    *pour cela, il suffit d’écrire à malicence@1-more-thing.com depuis une adresse e-mail référencée.

  • Événement gratuit : Présentation de FileMaker 17

    Événement gratuit : Présentation de FileMaker 17

    [Mise à jour : à cause de 22 personnes dont 11 belges courant après un ballon, la date est reculée de deux jours Pendant un Uruguay-Arabie Saoudite]

    La nouvelle version de FileMaker vient de sortir, avec son lot de nouveautés, son nouveau modèle de licences, et de bonnes pistes pour entrevoir la direction prise par la plateforme.

    Venez découvrir ces nouveautés autour d’un verre le 18 20 juin 2018 à 17:00, avenue de la Couronne 382, 1050 Bruxelles.

    Merci de vous inscrire ci-dessous.

    [contact-form-7 id=”12958″ title=”Inscription à Présentation FM 17″]

     

    Ajoutez l’événement à votre agenda

  • Le 22 avril, venez courir avec nous

    Le 22 avril, venez courir avec nous

    Parce que nous aimons les données. Parce que la science moderne repose sur les données. Parce que nous avons besoin de la science comme la science a besoin de nous… et parce qu’on aime aussi bien rigoler…

    1-more-thing sponsorise les 10km de l’ULB (Université Libre de Bruxelles), au profit de la recherche scientifique.

    Pour le retour des beaux jours, si vous souhaitez passer un petit moment sympathique entre amis ou en famille (départ de la course des enfants à 9h30, départ adultes 10h30)

    Rejoignez notre équipe gratuitement (dans la limite des places disponibles). Inscrivez-vous simplement ci-dessous, nous reprendrons contact avec vous.

    Attention, 10km, c’est long. Le sport demande un peu de pratique. Entraînez-vous avant le 22 !

    running color

     

    Mise à jour (22/4/18). C’était aujourd’hui. On a bien rigolé, et bien fait avancer la science 🙂

     

  • RGPD en fête à Bruxelles !

    RGPD en fête à Bruxelles !

    [vc_row bg_color=””][vc_column][vc_column_text]Jeudi 1/3, c’était la fête dans nos locaux bruxellois, pour célébrer la prochaine entrée en vigueur le 25 mai prochain, du RGPD, le nouveau Règlement Général sur la Protection des Données.

    Fêter de nouvelles contraintes réglementaires imposées par l’Europe, voilà qui est pour le moins singulier, non ?

    RGPD salleSi nous avions choisi de donner un côté festif à l’événement, c’est parce que nous pensons, en tant que citoyens européens, que c’est une bonne chose de disposer d’un cadre juridique pour protéger nos données personnelles de l’appétit de certains  pour qui la quantité de données collectées prévaut souvent sur le droit de chacun au respect de sa vie privée.

    Par ailleurs nous considérons que cette obligation peut être vue comme une belle opportunité.

    Florence RDPDL’opportunité d’une part de se repencher sur la manière dont vous traitez, stockez, et même protégez les données personnelles dans les applications que nous développons pour vous.

    D’autre part, une opportunité de profiter de l’occasion pour réexaminer nos procédures et vérifier si elles sont bien en conformité avec les principes définis par le RGPD.

    À 18 heures donc, nos valeureux clients et invités, défiant le froid, la neige et les embouteillages, sont venus se réchauffer chez nous, et surtout s’informer sur cette nouvelle réglementation européenne. Florence de Villenfagne, consultante ICTLex et formatrice au Data Protection Institute, était notre invitée et a exposé le cadre juridique du RGPD ainsi que les principales implications.

    Sa présentation a été particulièrement appréciée. Elle avait pris le temps de s’enquérir des activités de chacun avant son intervention, et a pu ainsi proposer des exemples précis et très parlant.

    Tanguy Collès, désormais “certifié” DPO par le Data Protection Institute a ensuite pris la parole et a présenté les différents axes selon lesquels 1-more-thing évoluait afin de proposer le meilleur conseil possible à nos clients autour du RGPD.

    Il a abordé les aspects contractuels, juridiques, organisationnels et techniques. Nous avons vu que de grandes parties du RGPD était déjà présentes dans les règlementation antérieures, et que 1-more-thing avait déjà une bonne culture de la protection des données. Mais nous avons aussi vu qu’il fallait prendre un certain nombre de mesures -techniques et non techniques- pour se mettre en conformité.

    Après une session de questions/réponses, nous nous sommes déplacés dans l’open space, avons un peu poussé les bureaux, et donné corps au côté festif de notre soirée. Il serait difficile de décrire en détail cette deuxième partie de soirée, mais en deux mots : c’était très bon et très sympa ! Et pour ceux qui étaient là et qui ont demandé le nom du traiteur, voici ses coordonnées :

    Cerisaie S.A.
    Traiteur Evénementiel
    info@cerisaie.be
    T. +32 10 230 130
    Rue Laid Burniat, 3
    1348 Louvain-la-Neuve

    [/vc_column_text][/vc_column][/vc_row][vc_row bg_color=””][vc_column width=”1/1″][vc_gallery interval=”2″ images=”12509,12508,12507,12506,12505,12504,12503,12502,12501,12500,12499,12498,12497,12496,12495,12494,12493,12492,12491,12490,12489,12488,12487,12486,12485,12484,12483,12243″ img_size=”full”][/vc_column][/vc_row]

  • La sensibilité à la casse dans FileMaker

    La sensibilité à la casse dans FileMaker

    [vc_row bg_color=””][vc_column][vc_column_text]Voici peut-être un sujet un peu pointu, mais il ne fait jamais de mal d’interroger parfois les fondamentaux… essayons ici de faire le tour complet de la problématique de la casse en FileMaker.

    D’abord, pour ne pas se perdre tout de suite, qu’est-ce que la “casse” ?

    Ici, je parierais que beaucoup de ceux qui savent déjà ce qu’est la sensibilité à la casse ne savent pas d’où vient le mot.

    Ce terme nous vient de l’imprimerie, et plus précisément de la typographie : pour composer une page, il fallait attraper très rapidement des caractères en plomb. On les rangeait alors dans une sorte de caissette en bois compartimentée et que l’on appelait casse. Chaque compartiment contenait les plombs pour un caractère de la fonte (ou police). Or on ne les rangeait pas par ordre alphabétique mais par fréquence d’utilisation. Les minuscules étant bien plus employées que les majuscules, leurs compartiments devaient être proches du typographe, et donc en “bas-de-casse”, les majuscules en “haut-de-casse”.

    Pour ceux que cela amuse, je vous invite à réfléchir aux termes encore employés à l’ère de l’informatique : casse, fonte, valise de police…

    FileMaker comporte des fonctions de calcul qui nous permettent de manipuler la casse d’un texte :

    Ainsi que des fonctions qui permettent d’ajouter ou de retirer un style (dont la casse) :

    Mais… qu’est-ce donc que la sensibilité à la casse ? C’est très simple : selon les environnements et le contexte, on considérera qu’une majuscule a la même valeur qu’une minuscule (insensibilité à la casse) ou au contraire qu’elle a une valeur différente (sensibilité à la casse)

    Par exemple dans un dictionnaire français comprenant des noms propres, comme par exemple le Larousse, on ne fera pas de différence de classement entre une majuscule et une minuscule, ainsi un nom propre avec une majuscule se retrouvera parmi des noms communs, adjectifs ou autre adverbes en minuscules.

    dictionnaire

     

    Dans d’autres contextes, on fera nettement la différence.

    Bien souvent dans les langages informatiques, la plupart des traitements sont effectués avec sensibilité à la casse. Cela vient notamment du fait que les premiers ordinateurs travaillaient sur des jeux réduits de caractères (ASCII), et ne pouvaient se permettre de s’encombrer de considérations telles que a = A à chaque fois qu’ils devaient analyser un a.

    Mais FileMaker, qui comme vous le savez a été pensé pour des humains normaux (ou presque), fait l’effort depuis très longtemps de l’insensibilité à la casse. Ainsi, vous pouvez comparer des chaînes de caractères telles que “Milan” (la ville) et “milan” (le rapace), et constater une égalité :

    "Milan" = "milan"

    Ceci fonctionne aussi bien dans les calculs que dans les index (utilisés dans les liens, listes de valeurs ou recherches).

    D’ailleurs, on peut noter qu’il en est de même avec les caractères accentués : “à” = “a”, si toutefois la langue d’indexation est le français (en russe par exemple, le E (yé) et le Ë (yo) sont bien deux lettre différentes, avec chacune sa place dans l’alphabet et dans le dictionnaire. Mais il s’agit de caractères différents de l’alphabet latin, bien que visuellement similaires)

    On pourrait donc penser que “FileMaker n’est pas sensible à la casse”, un point c’est tout.

    Or ce serait bien ennuyeux si on en restait là.

    Il existe un nombre limité de cas où FileMaker est sensible à la casse (case sensitive en anglais), essayons d’en faire le tour.

    Tout d’abord, certaines fonctions de calcul le sont. On en cite souvent trois en oubliant que FileMaker continue d’évoluer et que ça n’est pas parce qu’en 1914 il y en avait trois qu’il y en a forcément trois aujourd’hui.

    Voici donc les trois “connues” :

    • Filtre ( TexteAFiltrer ; TexteFiltre ) – Filtre ( “AaBbZ” ; “aZ” ) retournera “aZ” et non “AaZ” : le A majuscule est éliminé par le filtre
    • EstEgal ( TexteOrigine ; TexteComparaison ) – EstEgal ( “monMotDePasseSuperSecret” ; “monmotdepassesupersecret” ) retournera 0 car les deux chaînes ne sont pas identiques, alors que, rappelons-le, “monMotDePasseSuperSecret” = “monmotdepassesupersecret” retournera 1 (l’opérateur de comparaison = n’est pas sensible à la casse). Soit dit en passant, si votre mot de passe est super secret, préférez une comparaison de hash MD5 plutôt que de stocker le mot de passe en clair dans la base de données !
    • Substituer ( Texte ; ChaîneRecherchée ; ChaîneRemplacée ) – Substituer ( “Bébé” ; “b” ; “d” ) retournera “Bédé” et non “dédé”; car B et b sont deux caractères différents pour cette fonction sensible à la casse.

    Et donc on aurait ainsi fait le tour de la question ? Que nenni…

    Depuis FileMaker 12, la fonction ExecuterSQL ( RequêteSQL ; séparateurRubrique ; séparateurLigne{; arguments…} ) –  entrouvre la porte au langage de requête SQL au sein de FileMaker (d’un point de vue strict, cette porte était déjà entrouverte pour les connexions ODBC ou les plugins). Or SQL est en grande partie sensible à la casse, même si là encore, l’implémentation de FileMaker est assez tolérante.

    Soit une table “maTable” contenant les colonnes “champ1” avec les valeurs A1, A2, A3, et “Champ2″ et les valeurs  B1, B2, B3 :[/vc_column_text][ish_table align=”center” header_bg_color=”color7″ header_text_color=”color4″ border_color=”color7″]

    ID champ1 Champ2
    1 A1 B1
    2 A2 B2
    3 A3 B3

    [/ish_table][vc_column_text]La formule suivante :

    ExecuteSQL ( "SELECT champ1 from matable where champ2 = 'B3'" ; "" ; "" )

    retournera bien “A3”. Autrement dit, le nom des tables et des colonnes n’est pas sensible à la casse, mais c’est maintenant le cas de la plupart des implémentations SQL. Les mots clef comme SELECT, FROM ou WHERE dans cette requête sont toujours insensibles à la casse. Par convention, on les écrit en majuscules, sauf ici où j’ai voulu illustrer l’insensibilité à la casse.

    en revanche, la même formule dans laquelle on changera le critère ainsi :

    ExecuteSQL ( "SELECT champ1 from matable where champ2 = 'b3'" ; "" ; "" )

    retournera du vide, car “b3” n’est pas égal à “B3” dans une requête SQL.

    Astuce : si ce comportement vous dérange, vous pouvez utiliser la fonction SQL lower :

    ExecuteSQL ( "SELECT champ1 from matable where lower ( champ2 ) = 'b3'" ; "" ; "" )

    Donc il y a bien quatre et non trois fonctions sensibles à la casse…

    … est-ce tout ?

    Non ! depuis FileMaker 16, de nouvelles fonctions sont apparues :

    Au passage, on remarquera que FileMaker a apparemment décidé de ne plus traduire le nom des fonctions de calcul. Le traducteur a dû être sensible à la casse… sociale.

    Donc essayons cette formule :

    Uniquevalues ( list ( "a" ; "b" ; "B" ; "A" ; "à" ; "À" ) ; 1 ; "" )

    le résultat est :

    a
b

    donc aucune sensibilité à la casse.

    en modifiant légèrement, pour explorer :

    Uniquevalues ( list ( "A" ; "a" ; "b" ; "B" ; "A" ; "à" ; "À" ) ; 1 ; "" )

    le résultat est

    A
b

    donc on voit que le A majuscule est retourné à la place du a minuscule parce qu’il est trouvé en premier, mais comme on n’est pas ici sensible à la casse, le a minuscule n’est pas retourné en plus.

    Mais… n’avais-je pas sous-entendu que ces fonctions étaient justement sensibles à la casse ?

    Et bien… c’est qu’elles peuvent l’être !

    Le dernier paramètre (facultatif) de ces fonction est locale, et il permet justement de préciser dans quelle “langue” on veut trier ou dédoublonner.

    Or s’il est une langue que nous parlons vous et moi couramment, c’est bien… l’Unicode.

    Dans l’aide, vous constatez que deux variantes peuvent être utilisées : Unicode_Raw et Unicode_Standard.

    Uniquevalues ( list ( "a" ; "b" ; "B" ; "A" ; "à" ; "À" ) ; 1 ; "Unicode_Raw" )

    retourne

    a
b
B
A
à
À

    autrement dit chaque caractère est différent (accentué, non accentué, majuscule, minuscule…). Voici donc deux nouvelles fonctions (SortValues et UniqueValues) sensibles à la casse !

    Uniquevalues ( list ( "a" ; "b" ; "B" ; "A" ; "à" ; "À" ) ; 1 ; "Unicode_Standard" )

    retourne

    a
b
à

    on voit qu’on perd la sensibilité à la casse mais pas celle aux accents.

    Je crois que nous avons fait le tour de la question de la sensibilité à la casse dans FileMaker. J’espère que vous aurez appris quelque chose. N’hésitez pas à prolonger la discussion dans les commentaires ci-dessous.[/vc_column_text][/vc_column][/vc_row]

  • Urgence famine Afrique : vos licences FileMaker à la rescousse

    Urgence famine Afrique : vos licences FileMaker à la rescousse

    [vc_row bg_color=””][vc_column][vc_column_text]Vous n’en entendez peut-être même pas parler, mais plusieurs pays d’Afrique, notamment la Somalie, le Sud Soudan et le Nigeria connaissent actuellement une famine grave et qui est en train de tourner à la catastrophe majeure.

    La sous-médiatisation de cette famine entraîne un sous-financement des ONG capables d’agir. Or pour une famine, il faut agir très rapidement.

    On ne peut pas tout faire, mais ce qu’on peut faire, on doit le faire. Nous avons donc décidé de participer au financement de ces ONG, via Famine 12-12 en renversant la totalité de la marge que nous dégageons sur la vente de licences FileMaker.

    Dès à présent, toute licence FileMaker que vous commandez auprès de nous générera un don.

    Si le renouvellement de vos licences n’intervient pas rapidement, nous vous proposons de renouveler anticipativement et prenons bien sûr à notre charge la gestion de tout cela.

    N’hésitez pas à nous contacter pour en savoir plus.

    Et, si vous n’avez pas besoin de licences FileMaker mais que vous souhaitez soutenir cette action, n’hésitez pas et rendez-vous sur la page du projet ;-)[/vc_column_text][ish_counter el_text=”1641″ text_color=”color7″ tag_size=”h3″ icon=”ish-icon-heart” additional_text=” € collectés depuis le lancement de l’opération” icon_color=”color7″][/vc_column][/vc_row]

  • De retour de la dotfmp 2017 à Berlin

    De retour de la dotfmp 2017 à Berlin

    Comme tous les ans depuis 4 ans, nous nous rendons au mois de juin à Berlin, ou Egbert Friedrich @dotfmp organise “l’anti-conférence” dotfmp

    Une anti-conférence (unconference), c’est comme une conférence, mais au lieu de privilégier une transmission verticale (un orateur à son auditoire), on essaie d’en faire un lieux d’échanges horizontaux. L’orateur est plutôt un animateur d’une discussion à bâton rompu.

    Des discussions peuvent s’organiser à la volée, en réaction à une autre ou pour la prolonger. Bref, c’est plus un forum qu’une conférence.

    Cette année comme tous les ans, la crème de la crème des développeurs européens (et quelques américains habitués comme Steven Dolenski (@oceanwest), Chris Moyer @chrismoyer1 et Heidi Porter) étaient présents. 96 participants, soit un record. Andries Heylen @AndriesHeylen, Jean-Frédéric Struyven, Laurent Spielmann @laurent_at_joes et moi-même @FabriceN étions de la partie pour 1-more-thing.

    dotfmp audience

    Quelques nouveaux concepts marquaient cette édition : un nouveau site web développé par Andries Heylen, justement, qui permettait non seulement de partager l’information mais aussi d’interagir avec le planning, les fichiers à télécharger… bien sûr la base de données et le back office étaient en… FileMaker.

    Les salles étaient modérées par une personne désignée, qui s’assurait de la bonne tenue de la discussion, afin que les échanges soient le plus fructueux possible. Honnêtement, alors que j’avais personnellement accueilli cette idée avec enthousiasme, je n’ai pas beaucoup vu les modérateurs à l’œuvre, et parfois les prises de parole étaient trop longues ou des sessions étaient plus des présentations que des discussions (un peu comme dans une anti-anti-conférence)

    Autre nouveauté :  les inscriptions étaient payantes (mais raisonnables), mais ça n’a apparemment pas empêché l’affluence (il faudra trouver autre chose…)

    D’autres concepts demeuraient au contraire inébranlables, notamment la machine Espresso apportée par David Wikström @CamelCasedata et qui nous épargnait le café berlinois dont on dira poliment qu’il n’est pas à la hauteur de la bière qu’on peut déguster en fin d’après midi au Bier Garten en face du centre de conférence.

    Peter WagemansSur le contenu, voici mon point de vue très personnel. J’ai assisté comme toujours à des discussions et des présentations intéressantes. Je garde notamment en mémoire celles de Jeroen Aarts @JeroenAarts sur OAuth, de Peter Wagemans sur l’utilisation des robots sur le serveur, de Johan Hedman sur les outils de Business Intelligence, ou de Claus Lavendt @DataManix sur le potentiel des plugins avec le SDK.

     

     

    J’ai moi-même animé plusieurs discussions :

    • Trucs et astuces sur FileMaker 16
    • Potentiel de la nouvelle fonctionnalité des sources de données externes variables
    • Stockage externe des conteneurs : sécurisé vs ouvert

    J’ai été à chaque fois captivé par la faculté d’échange de notre communauté. C’était vraiment des discussions intéressantes.

    De manière générale, je m’attendais toutefois à plus de contenu spécifique à la version 16 de FileMaker, qui est à mon sens une révolution en plusieurs domaines. Peut-être était-ce dû à la proximité de la sortie.

    Néanmoins, c’était une belle édition. On se réjouit déjà de l’année prochaine !

     

  • Événement FileMaker 16 : formation pour développeurs

    Événement FileMaker 16 : formation pour développeurs

    FileMaker 16 pour les développeurs – un réel besoin de se former

    27 juin 2017 – Paris

    Réserver

    La sortie de FileMaker 16 en mai est très particulière. Alors que de version en version il suffit en général au développeur de parcourir la liste des nouveautés pour les comprendre, et quelques billets de blog pour en percevoir toute le potentiel, la plateforme FileMaker 16 ouvre de nouvelles portes au développeur FileMaker… à condition d’y consacrer un vrai temps de formation.formation FileMaker 16
    Afin de gagner du temps et de mettre toutes les chances de son côté pour entrer dans cette nouvelle ère sans dommage, 1-more-thing et son équipe d’experts vous proposent une journée complète de formation le 27 juin, au centre de Paris.
    Les places sont extrêmement limitées car il est important à nos yeux de pouvoir personnaliser cette formation et de répondre aux questions particulières.
    En sortant de cette formation, vous aurez acquis l’ensemble des compétences qui vous permettront d’utiliser les API tierces ainsi que l’API data de FileMaker.

    Aperçu du programme

    • Nouvelles méthodes d’authentification OAuth :
      • principes de l’authentification externe
      • avantages et inconvénient des systèmes de Microsoft, Amazon et Google.
      • exemple d’implémentation avec les services d’Amazon
    • Encryption. Nouvelles et anciennes méthodes : un point sur la sécurité
    • cURL et fonctions JSON : théorie et pratique
      • le http et les différentes méthodes (GET, POST, PUT, DELETE)
      • comprendre et manipuler les objets JSONRomain Dunand
      • cURL en détail : (presque) tout sur cURL et sur son implémentation dans FileMaker
      • qu’est-ce qu’un service REST ?
      • exercices autour d’exemples variés d’implémentation * :
        • analyse de la documentation d’une API REST
        • géolocaliser une adresse grâce à l’open DATA
    • Data API
      • Data API : un service RESTful ?
      • avantages et inconvénients par rapport à XML/PHP
      • travaux pratiques
      • node : pourquoi cela change tout

    * Les exemples d’implémentation peuvent être adapté en fonction des demandes

     

    Réserver

  • FileMaker 16 – Sources de données dynamiques

    FileMaker 16 – Sources de données dynamiques

    Pour chaque sortie majeure de FileMaker, il y a les fonctionnalités phare, mises en avant par l’éditeur, compréhensibles avec un simple screenshot…

    Et il y a les fonctionnalités moins en vue, qui sont souvent tout aussi importantes.

    FileMaker 16 ne déroge pas à la règle. Avec ce changement apparemment mineur que sont les sources de données externes dynamiques, l’horizon s’élargit considérablement pour les développeurs qui souhaitent distribuer leurs solutions ou proposer une application sur le cloud.

    Les solutions demandant la synchronisation entre FileMaker Go et FileMaker Server bénéficieront également de cette évolution.

    Au passage, on explore aussi dans cette vidéo les possibilités d’encryption au niveau de la rubrique (field-level encryption), mais uniquement à titre d’exemple.

    Et aussi —surtout— vous verrez mon chat.

     

  • Contrôle des fins de lignes (suite)

    Contrôle des fins de lignes (suite)

    Lors de la sortie de FileMaker 14, nous avions déjà publié un article sur ce sujet, car nous avions un début de solution à l’éternel problème des fins de ligne (LF, CR, CRLF) dans les fichiers exportés par FileMaker.

    Mais FileMaker 16 met un terme à cette éternité : le problème est désormais résolu de manière propre.

    Voici donc une petite vidéo qui explore la fonction TextEncode

     

     

     

  • FileMaker 16 – les fenêtres carte

    FileMaker 16 – les fenêtres carte

    FileMaker 16 est une immense étape pour notre plateforme favorite. Au point qu’il nous est difficile de résumer toutes les nouveautés dans une ou deux vidéo de présentation —même en nous cantonnant aux évolutions majeures.

    Aussi, nous avons décidé de publier dans les semaines à venir plusieurs vidéo plus spécifiques et approfondissant un sujet en particulier, toujours sous un angle un peu plus technique que ce que vous pouvez trouver par ailleurs sur le web.

    Voici la première d’entre elles : les fenêtres carte. N’hésitez pas à laisser des commentaires ci-dessous, et à nous donner votre ordre de priorité pour les sujets à traiter dans les prochaines vidéos !

     

  • ODBC Import technique

    ODBC Import technique

    [Version française]

    In this blog post, I will share a technique that Laurent Spielmann (@laurent_at_joes) and I developed together and that greatly simplifies imports. It uses ODBC import.

    Have you never been bothered by inconsistent database structures between a data source and your own application?

    Have you never cursed the SQL developer who uses as a unicity key a concatenation of several columns?

    Have you never felt anxiety before renaming a field because it could break an import order?

    Have you never lost your temper in front of a progress bar during a sync operation on a ESS table?

    If you answered no to all of these, I’m jealous. This article is for the rest of us. 🙂

    Some technical background for a start

    FileMaker has had a great friend for a long time: ODBC.

    ODBC is implemented in 3 very different manners in FileMaker. Let’s avoid confusion:

    1. FileMaker can be defined as an ODBC data source. It is not our topic today but it’s interesting because a FileMaker source interrogated via ODBC will act as any other database. An ODBC driver is provided with FileMaker Pro and FileMaker Server.FileMaker ODBC driver
    2. FileMaker can access ODBC data in the context of ESS (External SQL Source). The purpose is here to interact with external data as if they were FileMaker data, through table occurrences, layouts, scripts…). Since FileMaker 9, we used to be able to play with mysql, Oracle and SQL Server. Since the release of FileMaker 15, Postgresql and DB2 have joined the game. Note that on Mac, a third party driver is required (Actual Technologies). Since the release of ESS in FileMaker 9, developers tend to use it for all interactions with SQL sources. And that is a very bad idea. I admit that the fact that you can interact with external data just as if they were FileMaker data is great, but the cost in terms of performance is huge. ESS performance is well below ODBC potential.
    3. Finally, and that is often forgotten -and therefore our today topic— the capability to communicate with a SQL source by script.

    What script steps are we talking about?

    Two script steps allow interaction with ODBC sources:

    1. READ: Import records.
    2. WRITE: Execute SQL (I’m not talking about the ExecuteSQL calculation function, that can only read (SELECT), but of the Execute SQL script step, for good)

    Note that it is not possible, at least to my knowledge, to read data from an external source without writing to a FileMaker table (import). One could expect that Execute SQL would return the result of a SELECT statement to a variable, but it doesn’t.
    Tip: Execute SQL can also modify the structure of a database. (CREATE, DROP, ALTER…). Come back to this tip after reading this article. Could give you ideas.

    Driver ? DSN ? what’s this?

    The main reason why these features are somehow neglected is that they require a DSN (Data Source Name) to be installed at the operating system level, and sometimes, depending on the database, a specific driver.

    A DSN is needed for the operating system to give applications access to an ODBC data source. ODBC is a standard that allows different databases to communicate using SQL. (Open DataBase Connectivity).

    On the Mac, you have to setup a DSN using ODBC Manager, that used to be installed by default in /Applications/Utilities/ before Apple decided it was too good for you. Fortunately, unlike MagSafe connector and other great hardware and software features removed by Apple, ODBC Manager can still be downloaded here.

    ODBC Manager

    While it is true that setting up a DSN on each client machine is complex, it’s a snap to install it once on the server.

    As a matter of fact, we’ve been able since FileMaker Server 9 to schedule scripts on server, and since FileMaker 13 to perform script on server from the client.

    What’s more, and while Import Records [ ODBC data ] has always been server compatible, Execute SQL has become server compatible only with FileMaker Server 15. Enough to re-think some stuff!

    To sum up: you can now set up a DSN only on the server and benefit from it on all clients, including Pro, Go, WebDirect and CWP.

    However, the developer (that’s you) will also need to access the SQL sources in order to write scripts (namely to configure import orders). To address this you’ll simply have to set up the same DSN on your computer, paying attention to using exactly the same name. So you will be able to edit your scripts and the server can perform them.

    We’re done with the technical setup. Now let’s focus on what’s interesting.

    The plot

    Here is a short summary of the situation we had to address. We have to import a massive amount of data stored in mysql.
    Performance is a key here, and this excludes ESS immediately. By the way, we had really no reason to consider ESS: this technology is good at one thing only: present and manipulate external data as if they were FileMaker data. Nothing else. It’s really NOT designed to import or run synchronization operations.
    So we go for ODBC imports, but refinements are to come later.

    First challenge: unicity and performance

    So here we are with the following script configuration:

    blog import odbc query basic

    As you can see, the Import records script steps is talking to a DSN with a query that we define as a variable for the sake of readability.

    But among the numerous imports we have to make, some are of ‘update’ type (the third option checked in the import order dialog)

    Import matching records

    The problem is that the unicity criteria does not fit in a single column. To decide wether a record matches and must be updated, 3 columns had to be used as matching keys.

    FileMaker allows this, but with dramatically poor performance. Since the number of records was huge, this simply wasn’t an option.

    Imagine the query:

    SELECT a, b, c, d FROM myTable

    But although we want to import these 4 columns into 4 FileMaker fields: A, B, C, and D, we must update records if a, b and c are matching A, B, and C.

    Let’s define the import order like:

    import order 1

    but we know that performance won’t be acceptable.

    One way —I’m serious here— would be to ask the SQL developer to update the view and add a column that would concatenate the 3 others. In our situation it would have been a reasonable option, but very often you have simply no control over the source structure.

    Let’s see if we couldn’t have mysql do the work for us…

    First, let’s create a FileMaker calculation field that will be a unique key on the destination side.

    K is a calculated field such as

    A & B & C

    Now, let’s update the query like:

    SELECT CONCAT (a, b, c) AS K, a, b, c, d FROM myTable

    Some explanations:

    • a 5th column is created on the fly (concatenation of a, b, and c).
    • we move before the others (optional, that’s just to show them who’s the boss.)
    • it’s renamed K, just because it looks nice (but you’ll see, that will give us ideas. Beauty IS important.)

    By selecting the Matching names options, we end up with this:

    import order 2

    and that is way faster!

    Second challenge: naming

    Wait! that’s interesting, isn’t it? OK, we solved the performance issue, but while doing so we really took control over the left side of the import order dialog (source).
    And one of the great issues we face with import records in FileMaker is it’s fragility. The only way to maintain an import order, even if you create or remove fields is to choose Matching names, but then you’re exposed to the consequences of renaming.

    As we just saw, we can control the name of the left side columns. Those who already used XSLT to import XML data already knew, but it’s worth mentioning.

    In the above example, I simplified the column names in a, b, c, d and the field names in A, B, C, D, but as you probably expect the real world names were a bit more complex.

    Imagine that the original request would be:

    SELECT name_first, name_last, jobTitle, date_of_birth FROM PEOPLE

    and that the target field names would be

    firstName, surName, occupation, dob

    we can write:

    SELECT name_first AS firstName, name_last AS surName, jobTitle as occupation, date_of_birth as dob FROM PEOPLE

    and with the concatenation:

    SELECT CONCAT (name_first, name_last, jobTitle) AS K, name_first AS firstName, name_last AS surName, jobTitle as occupation, date_of_birth as dob FROM PEOPLE

    Fantastic! we can now use the Matching names option!

    Still we knew that the SQL developer might want to rename some columns, or even release new views to replace the old ones after some weeks (this is a real case, not fantasy)
    So we wanted to build a system that would resist a change on the source side. Not that the change would be entirely automated, but we wanted to be able to switch to a new source in minutes, without coding. That’s where our work began.

    The nice little trick

    Wouldn’t it be nice if each FileMaker table was able to generate it’s own import query?

    We saw that the left side of the import order could be managed on the fly. It is therefore up to the right side (the database structure) to contain the information.

    One spot seemed nice for this: field comments.

    Let’s create a small syntax that will:

    • declare the left side column name. We’ll use a tag, “SOURCENAME:” followed by the source column name.
    • allow to modify this name easily: we’ll simply have to change the column name that follows the tag.
    • to comment out. If // is found before SOURCENAME:, the tag is ignored
    • not interfere with other information you’d like to place in the comments. As you can see on the image, you can combine a source name and some other comments.

    field comments

    Then we need to create a custom function. (the code is available in this text file)

    custom function

    It might look a little complex at first glance but:

    • a great part of the work is done by 2 other functions written by Agnès Barouh, CustomList and FilterList, that we renamed list.custom and list.filter. As a side note, Agnès now develops the Ti’Sac, that we sincerely recommend (it’s not simple politeness here, it’s a amazingly clever, unique, patented purse). Christmas is coming, so you should definitely take a look here.Ti'Sac
    • if it wasn’t a bit complex, you’d be disappointed.

    In fact, this function code doesn’t matter. If for the above mentioned table we evaluate the following expression:

    sql.query.import.map ( "" ; "contacts AS C" )

    the empty parameter indicates “current table”. One can also write:

    sql.query.import.map ( "people" ; "contacts AS C" )

    the result is:

    SELECT "C"."CIE" AS "company", "C"."familyname" AS "name" FROM "contacts" AS "C"

    which is exactly the query we need to pass to the script step Import records to have consistent source and destination names.

    Here is the same image again:field comments

    • Field ‘company’ will receive data from column ‘CIE’
    • Field ‘excluded’ won’t receive data
    • Field ‘inactive’ won’t either
    • Field ‘name’ will receive ‘familyname’

    And conflicts with SQL reserved words are avoided using quotes.

    The second parameter, “contacts AS C”, could have been “contacts”, but the function supports table aliases. This will allow importing from joints in the future (currently not supported by the function)

    Finally, this second parameter is optional, so you can inject SQL functions in the query:

    sql.query.import.map ( "" ; "" )

    returns:

    SELECT "CIE" AS "company", "familyname" AS name

    So if you need to do more complex things you can:

    sql.query.import.map ( "" ; "" ) & ", CONCAT ( column1, column2 ) AS myField FROM contacts"

    As you can see, this techniques opens up a lot of possibilities. Whether you’re importing from an external source or from the FileMaker database itself.

    If you combine this with the fact that an import script step is able to create a new table, that Execute SQL is able to delete this table (DROP), that you can now duplicate a record set without being limited because a table cannot import to itself, etc, etc… the potential is huge!

    Do not hesitate to leave a comment here, and now it’s up to you to explore!

  • Une exploitation de l’import ODBC

    Une exploitation de l’import ODBC

    [English version]

    Dans cet article, je vais vous exposer une technique que nous avons développée avec mon collègue Laurent Spielmann (@laurent_at_joes) et qui nous permet de simplifier grandement les imports. Elle utilise l’import ODBC.

    N’avez-vous jamais été embêté par les incohérences de structure entre une source de données que vous deviez importer et la structure de votre application ?

    N’avez-vous jamais maudit le développeur SQL qui utilise comme identifiant unique une concaténation de plusieurs colonnes ?

    N’avez-vous jamais craint de modifier le nom d’une rubrique de peur de casser des ordres d’importation ?

    N’avez-vous jamais pesté devant la lenteur de synchronisations avec des tables ESS ?

    Si vous avez répondu non à toutes ces questions, je vous envie. Cet article est fait pour tous les autres. 🙂

    Un peu de technique pour commencer

    Connaissez-vous l’histoire de l’ODBC ? Comment il vécut ? Comment il vit encore ?

    Et bien écoutez l’histoire de l’ODBC et FileMaker.

    Alors voilà, FileMaker a un bon ami, il est puissant et compatible avec plein de bases de données (on s’éloigne un peu de Gainsbourg, mais ça allait commencer à être pénible) : l’ODBC.

    L’ODBC est présent de 3 manières bien distinctes dans FileMaker, et il est très important de ne pas confondre :

    1. FileMaker peut être une SOURCE de données ODBC. Dans ce qui nous occupe aujourd’hui, c’est intéressant parce qu’une base de données FileMaker comme source de données ne sera pas différente d’une autre base de données. Un driver ODBC est fourni avec FileMaker Pro et FileMaker Server.FileMaker ODBC driver
    2. FileMaker peut exploiter une source de données ODBC dans le cadre de l’ESS (External SQL Source). Le but est ici d’interagir avec des données externes comme avec des données FileMaker (en créant des occurrences de table, des modèles, et en permettant aux commandes et scripts d’agir sur ces données). Depuis FileMaker 9, nous avions à notre disposition mysql, Oracle et SQL Server. Depuis FileMaker 15 Postgresql et DB2 sont de la partie. Notons que sur Mac un driver de chez Actual technologies est nécessaire. Depuis l’apparition de l’ESS, les développeurs FileMaker ont tendance à l’utiliser pour toute interaction avec les sources SQL. Or c’est une très mauvaise idée, car si la similarité des traitements avec les données FileMaker est quasiment magique, le revers de la médaille est la performance, très, très en dessous des capacités de l’ODBC.
    3. Enfin, et c’est vraiment la grande oubliée, et donc le sujet de cet article, la possibilité pour FileMaker d’interagir avec une base de données ODBC par script.

    De quels pas de script parle-t-on ?

    Deux pas de script permettent d’interagir avec une source de données ODBC :

    – en lecture : Importer enregistrements.

    – en écriture : Exécuter SQL (attention, on parle bien du pas de script et non de la fonction de calcul ExecuterSQL, qui ne fait que lire (SELECT))

    On notera qu’il n’est pas possible de lire des données d’une source externe sans les écrire dans une table FileMaker (importer). On aurait pu espérer que Exécuter SQL qui lance bien, comme on peut l’observer dans les logs d’un serveur SQL, une requête de lecture (SELECT), soit capable de retourner le résultat de cette sélection, mais ça n’est pas le cas. C’est bien dommage, mais si on le sait… (astuce : vous pouvez même utiliser Exécuter SQL pour modifier la structure d’une base. Revenez à cette astuce après lecture de l’article, et ça devrait vous donner quelques idées)

    Driver ? DSN ? c’est quoi donc ?

    La raison principale pour laquelle ces fonctionnalités ont été si négligées est qu’elles demandent l’installation d’un DSN (Data Source Name), et parfois, selon les sources de données, d’un driver spécifique.

    Un DSN est le moyen qu’utilise le système d’exploitation pour donner accès aux applications à une source de données ODBC, ODBC étant lui-même un système d’interopérabilité des bases de données entre elles. (Open DataBase Connectivity).

    Sur Mac, cela se configure avec ODBC Manager, que l’on trouvait dans le dossier Utilitaires du dossier Applications avant qu’Apple ne décide de supprimer cette fonctionnalité. Heureusement, contrairement au MagSafe, vous pouvez encore le télécharger ici.

    ODBC Manager

    Or s’il est complexe de déployer ce DSN sur tous les postes clients, il est très simple de le faire sur le serveur.

    Il se trouve que depuis FileMaker Server 9, on peut programmer des scripts sur serveur, et que depuis FileMaker Server 13, on peut exécuter un script sur serveur à la demande depuis le client (Exécuter script sur serveur).

    D’autre part, alors que Importer des enregistrements depuis une source ODBC a toujours été compatible serveur, Exécuter SQL n’est compatible que depuis FileMaker 15. De quoi se re-poser certaines questions !

    Pour dire les choses très rapidement : il est possible de ne configurer le DSN que sur le poste serveur et d’en faire bénéficier tous les postes client (y compris Go, WebDirect, et publication web personnalisée).

    Toutefois, le développeur aura également besoin d’accéder aux sources de données afin d’écrire ses scripts : rien de plus simple, il suffit de configurer le DSN sur sa machine également, en prenant bien soin d’utiliser exactement le même nom. Ainsi vous pourrez composer vos scripts et le serveur pourra les exécuter.

    Voilà pour la “plomberie”. Maintenant nous pouvons nous concentrer sur l’intéressant.

    La situation

    Voici donc un bref exposé de notre problématique. Nous devons importer des données depuis une base de données mysql.

    Le volume est très important, ce qui exclut directement ESS (et d’ailleurs, on n’avait vraiment aucune raison d’utiliser ESS). J’insiste : cette technologie n’a pour but QUE de présenter et manipuler des données externes dans FileMaker comme s’il s’agissait de données FileMaker. Elle n’est absolument pas faite pour des imports ou des synchronisations. Elle est très lente et absolument à proscrire pour cette exploitation. On s’oriente donc directement vers un import ODBC. Mais les subtilités viennent ensuite.

    Premier problème : la clef unique et la performance

    Nous voici donc partis avec la configuration du pas de script suivant :

    blog import odbc query basic

    Comme vous le voyez, on s’adresse à un DSN avec un requête, ici définie dans une variable par soucis de lisibilité.

    Mais parmi les nombreux imports que nous devons réaliser, certains sont de type “mise à jour” (avec la 3ème option cochée dans la fenêtre de définition de l’ordre d’importation)

    Import matching records

    Le problème est que le critère d’unicité ne tient pas dans une seule colonne. Pour décider si un enregistrement correspond et doit être mis à jour, il faut que 3 critères soient égaux.

    FileMaker permet tout à fait cela, mais au prix de performances catastrophiques. Au vu du volume (on parle en centaines de milliers d’enregistrements par jour), c’est tout simplement impossible.

    Imaginons la requête :

    SELECT a, b, c, d FROM myTable

    Mais bien que nous voulions importer ces 4 colonnes dans 4 rubriques FileMaker A, B, C et D, nous devons mettre les enregistrements à jour si a, b et c sont identiques à A, B et C.

    Nous pouvons configurer l’ordre d’importation ainsi :

    import order 1

    mais nous savons que les performances ne seront pas acceptables.

    Une solution serait de demander au développeur de la vue mysql d’ajouter une colonne qui concatènerait les trois qui nous intéressent. Dans notre cas, c’est envisageable, mais dans bien des cas, on s’adresse à une base de données dont on ne maîtrise pas la structure.

    Voyons si nous ne pourrions pas faire travailler mysql pour nous…

    Tout d’abord, créons une rubrique calculée dans FileMaker qui jouera le rôle de critère d’unicité.

    K est une rubrique calculée telle que

    A & B & C

    Maintenant, modifions la requête SQL ainsi :

    SELECT CONCAT (a, b, c) AS K, a, b, c, d FROM myTable

    Explication :

    • nous créons à la volée une 5ème colonne (résultat de la concaténation de a, b, c, d).
    • nous la plaçons en 1ère position (facultatif, c’est juste histoire de prouver qu’on a le contrôle)
    • on la renomme en K pour faire joli (mais on va voir que l’esthétique donne des idées)

    Résultat, sélectionnant l’option Matching names (noms concordants), on arrive à ceci :

    import order 2

    et ça, c’est très, très nettement plus performant !

    Deuxième problème: le nommage

    Oh ! mais c’est intéressant ce qu’on vient de voir. D’accord nous avons résolu notre problème de performance, mais en plus on a pris le contrôle des noms de champs à gauche (source). Or un des grands problèmes que nous avons avec les imports dans FileMaker, c’est la fragilité. Le seul moyen de maintenir un ordre d’importation même quand on crée ou qu’on supprime une rubrique, c’est de choisir l’option Noms concordants (Matching names), mais alors on s’expose aux changements de noms de part et d’autre.

    Or on vient de voir qu’on pouvait contrôler le nom des colonnes à gauche. Ceux qui ont déjà importé des données XML à l’aide d’XSLT le savaient déjà, mais ça mérite quand même d’être précisé.

    Dans notre exemple, que j’ai volontairement simplifié en nommant les colonnes a, b, c, d et les rubriques A, B, C, D, les noms n’étaient pas exactement ceux-ci, comme vous vous en doutez.

    Imaginons donc que ma requête d’origine ait été :

    SELECT name_first, name_last, jobTitle, date_of_birth FROM PEOPLE

    et que mes rubriques de destination aient été

    prenom, nom, profession, dateDeNaissance

    Je peux très bien écrire :

    SELECT name_first AS prenom, name_last AS nom, jobTitle as profession, date_of_birth as dateDeNaissance FROM PEOPLE

    et avec la concaténation :

    SELECT CONCAT (name_first, name_last, jobTitle) AS K, name_first AS prenom, name_last AS nom, jobTitle as profession, date_of_birth as dateDeNaissance FROM PEOPLE

    Fantastique ! on peut donc maintenant utiliser l’option Noms concordants !

    Reste que, et c’était tout à fait notre cas ici, on sait qu’il peut passer par la tête de notre développeur SQL de changer le nom de ses colonnes. Voire, c’était ici prévu, de changer complètement la structure des vues au bout de quelques semaines d’exploitation. Nous allons donc prendre les devants et créer un système qui permettra de résister à ce genre de choses, c’est-à-dire que l’on veut être capable, en quelques minutes, de changer la source de données et d’adapter notre code, sans, justement, coder. C’est ici que notre travail commence.

    La petite technique de derrière les fagots

    Ne serait-ce pas idéal si chaque table FileMaker était capable de générer son propre ordre d’importation ?

    On a vu que la partie gauche de l’ordre d’importation pouvait être contrôlée “à la volée”. C’est donc à la partie droite (la structure de la table) de contenir l’information.

    Un endroit pour cela : les commentaires de rubrique.

    Développons donc une petite syntaxe qui va nous permettre :

    • de déclarer le nom de la colonne à gauche : nous utiliserons “SOURCENAME:” suivi du nom de la colonne à importer.
    • de modifier facilement ce nom : il suffit donc de changer le mot qui suit cette balise.
    • d’être désactivable (notion de mise en commentaire) : si la marque de commentaire // est trouvée avant la balise SOURCENAME:, celle-ci est ignorée
    • de ne pas interférer avec d’autres informations éventuellement contenues dans le commentaire : on peut, comme vous le voyez sur l’image, ajouter d’autres choses dans le commentaire.

     

    field comments

    Ensuite, créons une fonction personnalisée telle que : (le code est disponible dans ce fichier texte)

    custom function

    ça a l’air compliqué comme ça, mais il faut préciser :

    • qu’une partie non négligeable du travail est faite par deux autres fonctions personnalisées d’Agnès Barouh, CustomList et FilterList, que nous avons pris la liberté de renommer list.custom et list.filter. Entre parenthèses, Agnès développe désormais le Ti’Sac, que nous vous recommandons pour de vrai (et ça n’est pas juste par politesse : c’est un concept de sac à main absolument unique). À l’approche de Noël, vous devriez faire un tour ici.Ti'Sac
    • que si ça n’était pas un peu compliqué, vous ne nous aimeriez plus.

    En fait, peu importe ce qu’il y a dans cette fonction. Si pour la table précédente on évalue le calcul suivant :

    sql.query.import.map ( "" ; "contacts AS C" )

    le paramètre vide indique “la table active”. On peut aussi écrire :

    sql.query.import.map ( "people" ; "contacts AS C" )

    le résultat de la fonction est :

    SELECT "C"."CIE" AS "company", "C"."familyname" AS "name" FROM "contacts" AS "C"

    soit exactement la requête qu’il faut passer à l’instruction Importer enregistrements pour avoir quelque chose de cohérent à droite et à gauche.

    Je vous remets l’image correspondant au commentaires de rubriques pour bien comprendre :field comments

    • La rubrique ‘company’ va être alimentée par la colonne ‘CIE’
    • La rubrique ‘excluded’ ne fait pas partie de l’ordre d’importation
    • La rubrique ‘inactive’ non plus
    • La rubrique ‘name’ va recevoir la colonne ‘familyname’

     

    Le tout en évitant les mots réservés en SQL (les noms des colonnes sont entre guillemets).

    Le deuxième paramètre, “contacts AS C”, aurait pu être écrit “contacts”, mais la fonction supporte les alias de table. Ceci dans le but d’importer depuis des jointures (ce qui n’est pas actuellement supporté par la fonction)

    Enfin, ce deuxième paramètre est facultatif, ce qui vous permet d’injecter des fonctions SQL à votre requête :

    sql.query.import.map ( "" ; "" )

    retourne :

    SELECT "CIE" AS "company", "familyname" AS name

    Si vous avez besoin de faire des choses plus complexes, vous pouvez donc écrire :

    sql.query.import.map ( "" ; "" ) & ", CONCAT ( colonne1, colonne2 ) AS maRubrique FROM contacts"

    Comme vous le voyez, cette technique ouvre beaucoup de possibilités. Que ce soit lors d’imports depuis une autre base de données ou depuis la base de données elle-même.

    Si vous combinez cela au fait qu’un import est capable de créer une nouvelle table, qu’Exécuter SQL est capable de supprimer cette table (DROP), que vous pouvez désormais dupliquer un ensemble d’enregistrements sans être bloqué par le fait qu’une table ne peut s’importer dans elle-même, etc, etc… les possibilités sont immenses !

    Nous espérons vous avoir fait découvrir quelque chose. N’hésitez pas à laisser un commentaire ci-dessous ou à partager. À vous maintenant d’explorer ! 

  • FileMaker Pro 15.0.2 : la première mise à jour “in App”

    FileMaker Pro 15.0.2 : la première mise à jour “in App”

    Oh ! à première vue il ne s’agit pas d’une révolution, mais pour les utilisateurs de longue date de FileMaker Pro, c’est tout de même quelque chose !

    Aujourd’hui sont sorties les version 15.0.2 de FileMaker Server, de FileMaker Pro et de FileMaker Pro Advanced.

    La première chose qu’on fait normalement dans ce cas-là, c’est de se rendre sur la page de téléchargement du site de FileMaker pour y trouver les informations de version, et télécharger la mise à jour.

    Or aujourd’hui, on ne voit que cela :

     

    FileMaker download page

    Tant sous l’onglet Mac que sous l’onglet Windows, seule la version Server semble disponible.

    Et pourtant… les mises à jour des version Pro et Pro Advanced sont disponibles également, mais il faut passer désormais par un tout autre chemin pour ces mises à jour intermédiaires (dites v-revs)

    C’est depuis l’application elle-même (FileMaker Pro ou FileMaker Pro Advanced donc) que vous devrez procéder à la mise à jour.

    Pour ce faire, dans le menu Aide (Help), sélectionnez “Rechercher les mises à jour”Help Menu

    Vous êtes alors alertés qu’une mise à jour est disponible, dont vous pouvez lire les informations de version. Vous n’avez qu’à confirmer pour procéder à la mise à jour.

    Comme vous le verrez, la mise à jour ne pèse que 6Mo (ce qui nous change agréablement), et s’effectue très rapidement, sans quitter l’application ! Autre avantage sur mac : si vous avez choisi de travailler dans une autre langue que la langue de votre système d’exploitation, FileMaker ne vient pas réinstaller le pack de langue que vous aviez consciencieusement désinstallé.info 1502

    Seul petit hic, une fois qu’on a passé le dialogue avec les nouveautés de la version… plus moyen de les retrouver. Et aucun article de la base de connaissance (knowledge base) n’en parle (probablement une question de temps).

    Toujours est-il qu’un problème non négligeable a été résolu : certaines polices de type 1 empêchaient la création de fichiers PDF corrects (bug connu à partir de la 14.0.6 et de la 15.0.1). C’est maintenant corrigé. La compatibilité mac OS Sierra 10.12 est également de la partie.

     

    [Mise à jour] Les notes de version sont désormais disponibles, en Anglais, ici.

  • S’y retrouver dans les licences FileMaker

    S’y retrouver dans les licences FileMaker

    [vc_row bg_color=””][vc_column][vc_row_inner][vc_column_inner width=”1/1″][vc_column_text color=”color7″][ARTICLE OBSOLÈTE : l’offre de licences de FileMaker a complètement changé (et s’est grandement simplifiée) à l’occasion de la sortie de FileMaker 17, le 15 mai 2018. N’hésitez pas à nous contacter via ce formulaire pour toute information][/vc_column_text][/vc_column_inner][/vc_row_inner][vc_column_text]Si une chose est certaine, c’est que la simplicité d’utilisation des produits FileMaker ne se retrouve pas dans la grille tarifaire ! Pour quatre produits dont un gratuit, on avait déjà plusieurs centaines de référence.

    Avec les licences FileMaker 15, tout est plus simple : on a ajouté quelques pages ! 🙂

    Plus sérieusement, bien que le but soit de simplifier et de rendre plus lisible pour des nouveaux utilisateurs, il faut admettre que cette évolution n’est pas toujours facile à comprendre pour les clients existants, voire pour les revendeurs.

    FileMaker a bien publié un petit guide sous forme de FAQ, mais uniquement sur les nouvelles licences FLT. Beaucoup de questions demeurent.

    Nous allons donc essayer de vous aider à choisir vos licences FileMaker

    Les licences FileMaker qui existaient déjà

    Jusqu’à présent, la plupart des licences se focalisaient sur le nombre de postes (ordinateurs à équiper)
    La chose la plus importante à retenir est que la totalité des offres antérieures est reconduite. On peut toutefois regretter le choix de terminologie : FileMaker parle “d’anciennes licences” (legacy), ce qui laisse supposer qu’elles sont en voie de disparition. Or il n’en est rien !

    Licences à l’unité

    Approprié pour les indépendants ou les petites structures de moins de 5 postes sans FileMaker Server. Les mises à jour doivent être achetées séparément pour chaque unité (il n’y a pas de maintenance). Là encore, le vocabulaire est curieux : on parle de “particuliers”, or bien sûr cette offre est également accessible aux entreprises, indépendants et associations. Vous pouvez acheter ces licences à l’unité directement ici.

    VLA (Volume License Agreement)

    À partir de 5 postes et/ou 1 serveur. Achat perpétuel. Pensez bien qu’il faut ajouter un coût de maintenance annuel pour bénéficier des mises à jour. Cette offre, bien qu’encore très répandue pour des raisons historiques, est désormais rarement la plus intéressante (mais cela peut arriver !)

    AVLA (Annual Volume License Agreement)

    À partir de 5 postes et/ou 1 serveur. Même chose que le VLA, mais sous forme de location annuelle ou bi-annuelle. Cette offre est très fréquemment la plus intéressante, car elle est très souple (on peut chaque année diminuer le nombre de licences, et en ajouter à tout moment). Les mises à jour sont incluses.

    SLA (Site License Agreement)

    Ce type de licence n’est pas basé sur le nombre de postes mais sur le nombre de collaborateurs total d’une entreprise (pas uniquement des utilisateurs FileMaker, donc). C’est très intéressant si vous avez plus de 25 collaborateurs dont une grande proportion utilise FileMaker (à vrai dire, c’est même souvent intéressant avant ce seuil). Une particularité de l’offre SLA est que le serveur n’est pas limité en connexions. Attention au coût de maintenance annuelle pour bénéficier des mises à jour.

    ASLA (Annual Site License Agreement)

    Même chose que SLA, mais en location annuelle ou bi-annuelle. Sans coût de maintenance donc, les mises à jour sont incluses.

    SBA (Software Bundle Agreement)

    Ce type de licence est réservé aux éditeurs de logiciels conçus avec FileMaker Pro. C’est un cas très particulier et très rare, nous ne l’aborderons pas ici afin de ne pas ajouter de confusion.

    “Maintenance” annuelle

    nous mettons entre guillemets, car la terminologie FileMakerienne est particulière. Il s’agit en fait d’une assurance logicielle, qui vous permet de bénéficier des mises à jour majeures (version 14, 15…). Elle s’applique aux contrats “perpétuels” que sont le VLA ou le SLA, mais pas aux offres de location (AVLA, ASLA). Les mises à jour mineures (14.2, 14.3…) sont elles indépendantes de la maintenance.

    Connexions concurrentes (ou simultanées)

    les connexions concurrentes sont vendues ou louées par 5 et sont nécessaires pour les serveurs en VLA et AVLA, dès lors que vous souhaitez utiliser WebDirect ou FileMaker Go en connexion. Elles peuvent être achetées ou louées en même temps que votre licence FileMaker Server ou après. Elles sont associées à votre licence FileMaker Server, ce qui fait que lors de votre prochain renouvellement de maintenance (ou échéance de location), c’est le prix de votre serveur qui sera ajusté. Ces connexions demeurent disponibles.

    Download on the App StoreRappelons que FileMaker Go est gratuit et permet d’utiliser sans frais des fichiers installés sur l’iPhone ou l’iPad, voire partagés par FileMaker Pro. En revanche il n’est pas possible de partager une base de données en WebDirect sans FileMaker Server.

    Tarif “éducation”

    toutes les licences FileMaker existent en tarif “éducation”. Ce tarif, comme son nom ne l’indique pas, est accessible à toute organisation dont les statuts précisent qu’elle est sans but lucratif, ainsi qu’aux professeurs et étudiants !

    Parmi ce qui existait déjà, ce qui change

    Encore une fois, il est important de comprendre que TOUTES les options décrites ci-dessus demeurent disponibles.

    Il y a plusieurs changements :

    • le prix des connexions concurrentes évolue sensiblement (euphémisme !). Il est multiplié par 5* ! Toutefois, pour les connexions existantes (si vous avez déjà ajouté des connexions à votre serveur donc, en AVLA ou en VLA), le prix de la location (AVLA) ou de la maintenance (VLA) est maintenu jusqu’à 2018. Sachant qu’il existe des offres bi-annuelles, vous devriez être tranquilles jusqu’à 2020, à condition de ne pas ajouter de connexions simultanées. Clairement, si votre modèle économique repose sur les connexions simultanées, vous devez réagir avant cette date.
    • les termes de licence de FileMaker Server changent et ne permettent plus aux hébergeurs de proposer un service mutualisé. Néanmoins, ceux qui comme nous, avaient des licences en règle de FileMaker Server 14 peuvent continuer de proposer ce service.fmcloud.fm Le format de fichier étant le même entre 14 et 15, seule la fonction Tronquer table n’est pas disponible sur FileMaker Server 14. FileMaker Inc. incite donc à passer à un hébergement dédié ou à rappatrier vos fichiers sur vos propres serveurs, et ce probablement en attendant une offre cloud par l’éditeur lui-même (les indices ne manquent pas !). Toujours est-il qu’en attendant, nous ne voyons pas de solution réaliste : un hébergement dédié est trop cher pour la plupart des clients d’hébergement, et la compétence nécessaire et le coût d’un serveur en interne (serveur physique, maintenance, sécurité, réseau, bande passante…) est bien souvent déraisonnable. On est donc dans une situation intermédiaire où nous avons, en tant qu’hébergeur, décidé de maintenir notre service mutualisé en FileMaker Server 14, tout en continuant, bien entendu de proposer de l’hébergement dédié.
    • il est désormais possible d’associer un contrat AVLA à une licence FLT annuelle (voir plus loin), et ce même pour un seul poste (il fallait avant au minimum 5 postes pour un AVLA). Cela permet d’associer des licences par poste, dont notamment FileMaker Pro Advanced pour le(s) développeur(s).
    • la durée de vie de la version demo passe de 30 à 15 jours. Probablement aussi pour des raisons de sécurité ? 😉

    *Quelques exemples de prix HT en € de FileMaker Server avant/après pour l’AVLA

    Désignation FMS 13 FMS 14 FMS 15
    FileMaker Server 348€ 348€ 348€
    FileMaker Server +5 connexions 648€ 828€ 2754€
    FileMaker Server +10 connexions 948€ 1308€ 4464€
    FileMaker Server +15 connexions 1248€ 1788€ 6174€

     

    Nouvelles licences FileMaker “pour les équipes”

    Là où les modèles de licence à l’unité, VLA, AVLA s’intéressent au nombre de postes (PC) et au nombre de connexions simultanées (WebDirect, FileMaker Go), et où SLA et ASLA s’intéressent au nombre total de collaborateurs de l’entreprise (utilisateurs de FileMaker ou non), les nouvelles licences “FileMaker pour les équipes” (“FileMaker for Teams”) concernent le nombre d’utilisateurs, c’est-à-dire de personnes physiques utilisatrices de FileMaker Pro, Go ou WebDirect.

    Licences FileMaker pour les équipes
    Licences FileMaker pour les équipes

     

    Comme on le voit sur l’image, on retrouve désormais une tarification sous une forme devenue standard dans l’industrie.

    Ces nouveaux contrats, comme les autres, existent en perpétuel (achat) ou annuel (location). L’avantage est que c’est très simple et qu’il n’y a qu’un seul centre de coût : avec ces contrats, vous recevez un lien de téléchargement d’une version “gratuite” (incluse) de FileMaker Pro, qui vous permet de travailler en connexion avec le serveur. Ainsi vous n’avez pas à vous poser la question de comment un utilisateur va se connecter, mais simplement de combien d’utilisateurs vous avez en tout. [Rappelons que cette version “pour les connexions” de FileMaker Pro est une version complète, totalement fonctionnelle, de FileMaker Pro. Elle permet de modifier des fichiers, d’en créer, de travailler sur un fichier local… mais elle doit être connectée, au minimum toutes les 15 minutes, à FileMaker Server.]

    Cette offre est intéressante si vous avez 5 utilisateurs ou plus et qu’ils souhaitent se connecter de différentes manières à FileMaker Server. Cette offre ne répond pas au cas d’un grand nombre d’utilisateurs qui vont se connecter de manière occasionnelle : vous ne devez en théorie pas payer uniquement pour le nombre d’utilisateurs simultanés mais bien pour le nombre d’utilisateurs total. Dans ce cas donc, les connexions concurrentes demeurent la bonne solution.

    Autres points à remarquer :

    • FileMaker Pro Advanced est disponible à un tarif avantageux pour s’ajouter à un FLT (nous contacter)
    • Il n’est pas possible de cumuler une licence pour les équipes et des connexions concurrentes (par exemple vous avez 10 utilisateurs, mais vous souhaitez également ouvrir tout ou partie de l’application à vos clients, dont un maximum de 5 simultanés). La “solution” : 2 serveurs… (no comment…)

    En espérant que cet article vous permette de vous y retrouver. N’hésitez pas à faire appel à nous pour vos licences FileMaker, car comme vous le voyez c’est une matière qui demande d’être bien conseillé !

    [/vc_column_text][/vc_column][/vc_row]

  • Nouveautés de FileMaker 15

    Nouveautés de FileMaker 15

    FileMaker 15, la nouvelle version de la plateforme, et sortie.
    Comme c’est désormais l’habitude, tous les produits sortent simultanément (FileMaker Pro, FileMaker Pro Advanced, FileMaker Server, et bien sûr FileMaker Go).

    Contrairement aux versions précédentes où la liste des nouveautés était impressionnante, ce n’est pas le cas pour FileMaker 15.
    Cette particularité a plusieurs raisons :

    • la plupart des clients ont désormais un modèle annuel de licences. Soit par la location, soit par l’achat avec maintenance annuel, de sorte que le processus de mise à jour est moins spectaculaire qu’auparavant
    • FileMaker Inc. a clairement annoncé un cycle plus court de développement : une nouvelle version sort tous les ans, alors qu’auparavant on était sur des cycles variant entre 18 et 24 mois : on a donc moins de nouveautés, mais une adaptation plus rapide au marché et aux nouvelles technologies (très perceptible dans cette version de FileMaker Go)
    • FileMaker Inc. prépare désormais deux versions majeures en parallèle, cela permet de s’attaquer à des chantiers plus fondamentaux qu’il n’est pas possible d’amortir sur une version. C’est pourquoi, si l’on veut comprendre la direction prise, il est aussi intéressant de se pencher sur ce qui est dans la version que sur ce qui n’y est pas.

    Néanmoins, FileMaker 15 est une étape importante. Non seulement pour des raisons techniques, mais aussi par l’introduction d’un nouveau système de licences, qui va permettre de toucher d’autres publics, voire de proposer des solutions moins onéreuses et plus facilement gérables à des utilisateurs actuels. Dans d’autres cas, il faut aussi reconnaître que le prix des licences pourrait augmenter de manière significative. Il est donc très important de comprendre les nouvelles dispositions contractuelles.

    Hébergement

    Également, la version 15 marque la mort annoncée des services d’hébergement mutualisé. En effet, la licence d’utilisation de FileMaker Server ne permet plus ce type d’hébergement. Nos offres d’hébergement mutualisé fmcloud.fm, ainsi que celles de nos confrères soucieux de respecter les termes de licence, vont donc devoir rester en version 14. Bien sûr les offres dédiées (sur serveur physique ou virtuel) passent sans sourciller le cap de la 15.

    Dans cette vidéo, vous verrez ce qu’il faut retenir de cette version, en plus de ce qui vous a été montré dans la vidéo de Bilal Zian. N’hésitez pas à prendre contact avec nous si vous avez une question sur les licences ou sur des aspects techniques.

  • Réaliser une Master Detail View

    Réaliser une Master Detail View

    [English below]

    [OBSOLÈTE] : FileMaker 17 intègre cette fonctionnalité nativement.

    Depuis —presque— toujours, FileMaker propose trois vues différentes sur les modèles : les formulaires, les listes, et les tableaux. Or bien souvent, un mélange des deux est bien pratique pour pouvoir simultanément parcourir une liste d’enregistrements trouvés, et visualiser les détails de l’un d’entre eux en particulier, notamment pour l’éditer : l’interface Master/Detail ou Master Detail View.

    Ce type d’interface est archi-présent sous iOS, et l’était déjà dans la version desktop de Mail, comme d’Outlook d’ailleurs. Bref, c’est une interface typique que FileMaker ne propose pas nativement.

    MasterDetail View iPad

    Il se trouve que depuis quelque temps, plusieurs de nos clients de coaching nous demandent de l’aide sur cet aspect, et nous ont appris qu’il existait des techniques très complexes -et honnêtement pas très performantes- pour faire cela. Nous avons même reçu une candidature d’un développeur (excellent au demeurant) qui précisait sur son CV maîtriser le “Master Detail View” !

    Pourquoi faire simple ?

    … tout ceci à notre grande surprise, car nous réalisons ce type d’interfaces depuis très longtemps, et qu’il ne nous semblait pas que cela demande une expertise particulière. Au point que nous n’avions même jamais pensé à en faire un post de blog!

    En réalité, jusqu’à FileMaker Pro 13, c’était un tout petit peu plus complexe que cela. Il fallait utiliser une fonction personnalisée (qu’on pouvait notamment trouver chez Agnès Barouh). Désormais, rien de tout cela.

    Voici donc une petite explication sur une manière simple et efficace de créer un Master Detail View en FileMaker, qui ne limite pas le nombre d’enregistrement à afficher, et qui est tout aussi performante sur un réseau WAN que sur le LAN. Attention, si vous aimez les longs scripts et les déclencheurs dans tous les sens, vous allez être déçus 🙂

    Téléchargez le fichier de démo ici : Fichier 1MT_MasterDetailView.fmp12

    Concernant la video, si vous savez déjà ce qu’est une Master/Detail view, vous pouvez vous rendre directement à 2:40.

     


    If you already know what a Master/Detail view is, you can start the video at 2:40

    Create a ‘native’ Master Detail View in minutes

     

    [DEPRECATED]: this feature is built in FileMaker 17

    Since early days, FileMaker has been providing two, then three different types of view: form views, list views, and table views. Still, the appropriate interface, the one you often really want to offer to your users, would be a mix of a form view and a list view. The list then allows the user to quickly scroll through found records and browse to the one he/she wants to take a closer look at or edit. This type of views is called Master/Detail View or Master/Detail Interface.

    This type of interface is more than common on iOS, and was already in the desktop version of Mail or Outlook… The short story is: it’s a very common and appreciated interface, but FileMaker does not have it natively.

    MasterDetail View iPad

    During the past weeks, several customers to whom we provide coaching asked for help on this specific issue, and we discovered that there were very popular techniques, but we found extremely complex and not really performant, especially on a WAN network.

    Why make it simple?

    That was to our surprise, because we’ve been designing such interfaces for years, and we didn’t think it required specific skills. To such an extent we hadn’t even thought it was worth a blog post!… until a customer, a renown developer said this was definitely worth sharing.

    The truth is, until FileMaker Pro 13, the technique was slightly more complex. It required a custom function, among the fantastic ones shared by Agnès Barouh. But now, it’s even easier (and more performant)

    So here is an explanation on how to create a simple and efficient Master/Detail interface, not limited in the number of found records it can display, and absolutely usable on a WAN network. Warning: if you like long scripts, and triggers everywhere, you might be disappointed 😉

    Because the English version of our almost new website is still not available, you might have lost contact with us. Here are the next most important steps in your life 🙂

    UPDATE: Bruce Robertson added a valuable comment below about the lack of sorting feature in the showcased implementation. So if you really want to sort the list view (portal) like the found set (which sounds weird to me in terms of usability, but let’s not question this here), here is a different version taking advantage of the fact that whatever the method is, you will need a ‘manually’ (button) triggered script to reflect the sort change in the interface (at least to my knowledge).
    And as with other solutions I saw, when it comes to sorting, you’d better work with smaller found sets (or a limited portal row number). For this purpose I added a button to find only approx. 1000 records, but I left all data so you can have fun with larger found sets.

    Download this implementation with sort capabilities: Fichier MasterDetailView_sort.fmp12

  • FM AuditLog Pro 2.0 est disponible !

    FM AuditLog Pro 2.0 est disponible !

    [vc_row bg_color=””][vc_column][vc_column_text]Enfin ! les fidèles lecteurs de ce blog savent qu’on y travaillait depuis longtemps, mais il est enfin là, mieux encore qu’on ne l’avait imaginé au départ.
    FM AuditLog Pro 2.0 est un audit log (ou audit trail) pour vos bases de données FileMaker, incluant des fonctions de Roll-back.
    Entièrement natif, il ne requiert aucun plugin, et est parfaitement compatible FileMaker Pro, FileMaker Go, et WebDirect.

    Mais plutôt que de vous faire tout lire deux fois, regardez plutôt la page produit dans notre boutique.

    [/vc_column_text][/vc_column][/vc_row]