My username on the FileMaker community is “jeremy_fm_js”, and I’ve been known to advocate using JavaScript in FileMaker for a few years now. It might be interesting to be typecast into ‘the guy that always talks JavaScript’ (I don’t always recommend JS in my posts in the community), but I advocate for many good reasons. Some of them are reasons I’ve stated before, but also, there’s a few new ones I’ve thought of in the past year 🙂 If you need an escape hatch–this is, if you need to build an interface that is more interactive than we can do using ‘idiomatic‘ FileMaker–we can consider JavaScript, and we can consider learning the language. To help you learn JavaScript, JavaScript is part of FileMaker DevCon.

Why JavaScript?

The answer to this question is: why not JavaScript? There’s a lot of innovation we can bring to custom apps using the language native to FileMaker. JavaScript and JavaScript libraries brings thousands of testers to its foundation. I’ve written about all this before.

More reasons

FileMaker itself seems to be giving some weight to JavaScript in the platform (the entire platform, of course). There are two pieces of evidence. First, exploring JavaScript, for the third consecutive year, is part of FileMaker DevCon, the FileMaker conference. Along with APIs and Zapier and microservices, attendees will have the chance to see and experience what JavaScript can do in our apps.

Secondly, JavaScript is specifically mentioned in the product roadmap. In the past it’s been rare to see something so ‘outside’ of FileMaker be mentioned in the FileMaker plans, but there it is. So FileMaker, Inc, and my friends in the product-development team, must have some special plans for it.

The roadmap states: “Within a web viewer, directly call JavaScript from FileMaker scripts and vice versa.” That’s a very amazing idea. We will be able to solve certain web viewer problems with this functionality and give more control to FileMaker interacting with the JavaScript code.

JavaScript at DevCon

All day pre-conference training

This year I have the honor of leading folks in a full-day training of FileMaker & JavaScript. We will work together for six hours to talk about the following objectives and concrete activities.

Learn the basics of the JavaScript language

We’ll work together on exercises that teach us the basics of the language. We’ll talk about JavaScript concepts, and we’ll connect what’s true about JavaScript with what we already know in FileMaker.

Each exercise comes with one or more extra practices. We’ll do those to drive the point home.

Identify the peculiarities of the web viewer object on different devices

The web viewer object in FileMaker is powerful, but it is quirky. We have to understand its needs for each device, so as we practice and exercise, we’ll talk about how the web viewer works differently in different operating systems.

Integrate JavaScript libraries into any custom app

The fun of this day will be to spend time putting charts or data tables or any number of other libraries into our apps. We’ll learn how to do this from scratch. We’ll also review the tools out there that make this part very easy.

Just so you know: In order to work with libraries, we need to know a little JavaScript. We can’t run until we learn to walk.

Learn to communicate between JavaScript and FileMaker easily

The FM WebViewer Bridge framework is an important last-piece of the puzzle. It solves quite a few problems when working with the web viewer, and it provides a less jarring experience for your users. We’ll examine how this framework works.

We will work through examples and practices to learn more about how we can use JavaScript, and it will be a productive day. Attendees will learn a lot about how to use the language. We won’t be JS experts, but we will at least know a bit more of our way around its use in FileMaker. I have two ultimate soft goals:

To be comfortable enough with JavaScript we can look a JavaScript library in the face and not run away screaming in terror.

and

To expand our horizons of what is possible with FileMaker and JavaScript.

The six hours will be more than enough time to get our feet wet. If you haven’t signed up yet for this training time, I encourage you to give it a consideration. JavaScript brings to our fingers much power, and this session can help you see how to harness that power.

Discussions throughout the week

I wish to continue the JavaScript discussion well after the training session ends (after we’ve had a chance to recover from the workshop). Last year I was available to talk shop and sat with a few folks to talk one-on-one about how to integrate a chart or a data table into their in-production apps. That was a blast. So this year I wish to continue that. While at the booth or at food time or in the hallway, I’ll be available to talk with folks about their use of JS in their apps. So feel free to find some time with me and we can continue to discuss this innovative tool.

JavaScript after DevCon

The fun doesn’t end when FileMaker DevCon 2019 ends. Oh no. Energized from that experience, I’ll continue to talk about JavaScript and FileMaker. I’d love to do a follow up training session with interested folks to continue to learn more about the language and how to use it in FileMaker. So stay tuned to this blog and our Twitter page for more information.

Preparing for DevCon

If you do plan (or are thinking about) on joining me for FileMaker & JavaScript, please take a moment to download the file (below) and test your setup (computer, browser security settings, FileMaker version etc) to see if all will go well with your time. Basically click some buttons and confirm you see the web viewer user interface and interactions. Those running macOS will be fine. Windows users should really test it out.

I want you to be successful in the session. The file here contains a small sample of what we will do; all the items you’ll test here we want to make sure work. If you download the file and run thru the tests and all is good, you’ll have no issues with the work we do during the training. If you do have issues, please reach out to me at support@geistinteractive.com and we can work on finding a solution so that you can attend and learn and exercise your innovative spirit.

Don’t worry if your copy ‘fails’. I have a plan in case you can’t view the C3Chart or the DataTables or the PivotTable. The only extremely-vital one is the Code Editor test.

See yah in just a month! And get ready for JavaScript at FileMaker DevCon.

Download the Test File

WidgetStudio, the best tool out there to create and customize and deploy FileMaker web viewer widgets, is only a few months old. Yet its creator, Carson Lind of Eagle Optimizations, has added many new features to the dev tool. His goal was to make it easier to create and customize widgets. And he did so with the three big new features: Using an External Editor, Offline Compiler, and Easy Access to Variables.

Using an External Editor

The biggest feature–and the one we enjoy the most–is that WidgetStudio will now work with an external code editor. Though WidgetStudio provides a great basic editor for some widgets, most widgets we’ve built recently can get complex with many lines of code and many separate parts (HTML and some CSS and some JavaScript). WidgetStudio can now both sync a new or existing widget’s code from the files on the machine and ‘watch’ for any changes made to those files. A FileMaker developer can now use the editor outside of WidgetStudio, writing and organizing her code there, and then use WidgetStudio’s tools to customize and deploy that widget.

This is incredibly handy. Editors such as Visual Studio Code are commonplace among HTML / JavaScript developers. There are a lot of features built into these apps that make writing code efficient. And these developers can write code faster in an editor and in a more organized fashion.

Web Viewer widgets can get complex, having many different files. An external code editor helps organize. WidgetStudio can work with all of these.

Compile for offline use

Many widgets tap into additional JavaScript or CSS libraries that are found online somewhere. If this is the case, the widget must be able to reach that library, so the device must be able to access the internet.

WidgetStudio 2.0 now can compile for offline use. This means that any online resources such as JQuery or BootStrap that are available online will ‘sucked’ into the Widget at compile-time. WidgetStudio is clever in that it brings these online resources into a FileMaker table. And the widget then has all the libraries it requires without the need for being online.

WidgetStudio grabs the libraries that are hosted online and makes them available to your widgets.

Access to Variables

In WidgetStudio 2.0, widget creators can now access the variable settings much easier. While working in an external editor, the creator places variables to represent the customizable items. She needs to add additional settings to each variable to make it easy for a user to understand the value. WidgetStudio presents those settings with fewer clicks.

WidgetStudio truly gives us easier access to innovative web viewer widgets that enhance our user’s work and experience. And developers of widgets now have more tools to create and organize web viewer widgets. Check out the new features and download the demo. If you’ve already purchased WidgetStudio, you can get the update through your account here at www.geistinteractive.com or through the tool itself.

Today our FileMaker DevOps tool, Otto, gets a big upgrade; automated offsite backups to any S3 compatible storage service. Otto the only product that automates data migration, solution upgrades and offsite backups for on premises FileMaker servers. Otto 2.0 is now compatible with FileMaker 18 server.

Once Otto is installed on your server you can configure it to move a folder full of backups offsite. You can use S3’s storage retention policies to keep backups on S3 for as long or as short a time as you want. S3 is so cheap though, that you might just decide to keep daily backups stored there indefinitely.

Otto transfers Backups to S3

If your Workplace Innovation Platform Servers run on premises, then you need to make sure that you have a reliable backup method to make sure your valuable data is backed up offsite. Otto now has you covered.

Otto 2.0 is available today on our website. There is a free limited demo version available. Prices for the full version start at $400 for a 3-server pack. If you already have an Otto License, you can download this new version from your account on our website for free.

FileMaker 18 ups its game even more with a whole set of script steps (and a few functions) that allow us to write data to an external file. This can be done without an export. There’s a lot of potential in this FileMaker write data workflow.

I had the chance to play with these script steps and was aware enough to record the exploration. I knew only a little bit about these steps before I started. And during the exploration I learned a lot.

Here’s the recording. It’s rough and unedited. I prepared nothing for the video, so you get to see me developing and figuring this out as I talk (hopefully in a clear way).

So take a look at the video of the FileMaker write data workflow. It is 30 minutes. You’ll probably get a kick out of how I develop. After the video, I have a list of what I learned. Don’t read that yet! Watch the video first 🙂

Jeremy’s exploration of FileMaker write data workflow

What did you think of the video? Send me your thoughts about it here: support@geistinteractive.com. On to what I learned about the FileMaker write data workflow.

What I learned

Do you do this sometimes? DO you just build a test file and play around with a step or two? As I said in my video, I have thousands of files that explore single new features or help me study for the certification test. My desktop and a “databases” folder are littered with these. But they’re useful because I can test it out and build something for implementation later on.

I learned a lot in this exploration. Here’s what I learned.

  • You don’t have to just write to .txt files. Other file types will work, though I like the simplicity of the .txt file.
  • There’s a certain workflow, a certain order of steps to follow each time:
    • Check if the target file exists
    • Create it if it doesn’t
    • Open the file
    • Get the file’s size (to determine the next position to write to)
    • Write the data
    • Close the file
  • This process has to be in this order.
  • If I don’t close the file, I can’t open it again.
    • I wonder if I can write to it if I forget to close it. I bet I can.
  • In order to identify files, FIleMaker keeps an ID of each one. WE use the ID of the file to target the file to write or close.
  • There’s a few functions that identify open files and the position. So I’m using a combination of script steps and functions to do this work.

Some observations

  • I found the script steps that we use here that target a variable to be weird, something to get used to. I like them and I hope this trend continues, but it is weird. These steps can set the value to a field or a variable I like that.
  • Since this workflow is a specific order, I find it a good idea to modularize it. I did so in the video above. My public scripts call the “Write Data to File” script and they pass a JSON object ( of course) as a parameter. Here’s mine.
    I see this as an important piece: pass to the modular script the file name, the path, and the data as parameters from a parent script.
  • There’s a whole lot that we can do with this. . . I just haven’t thought through all those possibilities.

Onward

The new workflow: FileMaker write to data is just another star in FileMaker’s rank as the number one Workplace Innovation Platform. In an already-limitless platform, we can do even more.

 

FileMaker DevCon 2019 is fast approaching. There’s less than three months left, and we at Geist Interactive are busy, getting ready for the conference. Todd Geist and myself–Jeremy Brown–will attend (this will be our 20th and 8th time respectively) and spread the good word about JavaScript and the Workplace Innovation platform. We will be busy during the week, but will always make time for chatting about FileMaker or JavaScript or any other tech topic. Read on to see what we will be up to in Orlando, FL.

Conference Sponsor

Geist Interactive is proud to be a sponsor of this year’s FileMaker DevCon. We believe the three-day conference is great for every innovator out there. FileMaker DevCon 2019 will be full of great people, great innovations, and great food. We want to give back in the form of sponsorship so that all developers can learn as much as possible and make great connections.

Training Day

For the second year in a row, I will lead folks in a training session titled “JavaScript for FileMaker Developers“. This full-day session (upgraded from a half-day last year) will focus on how to use JS in our FileMaker apps. Attendees will spend time working on exercises in the JavaScript language. Each person will build a complete integration of a data table or a chart into a custom app. And everyone will learn how to work with the FileMaker Web Viewer object (which can be a bit prickly in some situations). Finally, we will focus on advanced topics like how to communicate to the JavaScript from FileMaker without causing a rude flash of the web viewer.

Our playground for the day.

I am dusting off my teaching skills and pulling out my manipulatives so that everyone–from the JavaScript beginner to the more advanced person–can learn something and walk away with a good set of next steps. Every FileMaker developer can (and should) use JavaScript as another tool in their apps. Join me in this session and learn how to use this powerful tool.

WorkPlace Innovation

Todd Geist is extemely a little obsessed with Workplace Innovation and FileMaker. He’s written about the beginning and the continuation of innovation with each incremental release of the platform. So at FileMaker DevCon 2019, Todd gets to speak about what he sees in the current status and the future trajectory of the Workplace Innovation Platform. Here is a description of his sessions:

Why a Workplace Innovation Platform?

What’s so special about a Workplace Innovation Platform? You’ve seen the videos, you’ve read all the marketing material, but practically speaking what is that makes a Workplace Innovation Platform standout from other options? We are going to look at the current state of business and work group innovation, and learn through a series of examples and mini case studies why FileMaker, as the leading Workplace Innovation Platform, can be so effective in driving business innovation.

What’s Next in Workplace Innovation?

Workplace Innovation doesn’t stop. Neither does the flow of exciting new technology that the FileMaker Workplace Innovation Platform makes available to us. In this session, we are going to look at some of my favorite bleeding-edge techniques, tools, and integrations that really make the FileMaker Workplace Innovation Platform shine. Come and see what the future looks like. There will even be some fun demos you can download and try on your own.

These two sessions are going to be lively and challenging and full, so you may want to show up early to get a spot.

No matter the size of the booth, we’re happy to talk all things Workplace Innovation Platform

Hanging at the Booth

Todd and I along with Tonya (another member of the team) will spend their time at our annual booth in the exhibit hall (though we do wish it were located down by the pool). We always welcome folks to come and stop by and talk anything you want. We’ll demo our products (FMPerception, Otto, WidgetStudio, GoDraw3, and many others) and our custom development offerings. So stop by for a spell and chat us up. Bonus points if you come ready to talk about, A. JavaScript; B. JSON; C. FileMaker Modules; D. Innovation in FileMaker.

Vendor sessions

At FileMaker DevCon 2019 we will feature FMPerception and Otto in two separate vendor sessions. Dave Ramsey will demonstrate the value added to your development using the only Realtime Developer Intelligence tool. He’ll open your eyes to the major features as well as the intricate details that really makes it more intelligent.

Todd will demonstrate what the best Dev Ops tool “Otto” do for you. He’ll walk you through how Otto can help automate the tedious and error-prone process of deploying, migrating, and monitoring solutions.

Check out the schedule as we get closer to DevCon. Stay tuned to us on social media for updates as well.

Packing our Bags (soon)

We’re getting ready for FileMaker DevCon 2019. We’re excited about all the innovations that will be on display and shared throughout the week, and we can’t wait to share a few of our own.

If you’ve never attended, check out my blog post on attending the conference for the first time from last year. Eventually he will post a new one with an updated theme 🙂

See yah in just a few months!

FileMaker 18 is another important step for the FileMaker Workplace Innovation Platform. It has a nice collection of new capabilities and features that make our jobs as Workplace Innovators even easier. But I like to take these now-yearly releases as an opportunity to step back, look at the bigger picture and fit this release into the broader trends that I see both inside FileMaker, the community and in Workplace Innovation in general.

The Beginning

Two years ago I wrote about how important FileMaker 16 was. I called it the Biggest Change Since FileMaker 7.  We got full cURL support, JSON parsing functions, a REST API and lots of others features that enabled FileMaker to become a first class citizen of the world wide web. It is hard to imagine being able to build apps today without access to those features.  But it was really only the very beginning of what was to become a major transition for FileMaker and the community. We are now well into that transition. In fact I’d say we have reached “The End of the Beginning”

Since FileMaker 16 shipped, several important things have happened or will be happening later this year. They show a company and a community that is more focused than ever and is fully engaged in strategy that I believe has a high chance of success.  Certainly there are challenges, more on this below.  But we are coming out of the awkward 🙂 beginning stage.

First Class Web Citizen

New features are great and individual companies and users can adopt them as soon as they are available.  But practically speaking the ecosystem as a whole is working with an average of the versions that are currently supported. There are still a lot of people using FileMaker 15, which does not support cURL and JSON.  Therefore the whole ecosystem doesn’t get to assume they can use JSON or any other feature in 3rd party products or sharable code, without excluding some portion of the ecosystem players.

Later this year FileMaker 15 will drop out of FileMaker, Inc.’s list of supported versions. All supported versions of the FileMaker Workplace Innovation Platform will be first class citizens of the web, able to integrate with just about any service, API, or app out there.

Modern Cloud Server

FileMaker 18 Server is the first version that has been built with core support for using multiple processors. While some of the benefits of this will take some time become obvious, we need to recognize how important this is.  Re-writing a database engine for a new feature like this is not easy. It’s not like just adding a new script step or a new layout control.  It is messing with a database’s highly optimized core job of writing data to disk correctly.

This had to get done for FileMaker to move fully into the cloud. We now have a server that has the required technical foundations to function as a cloud service or a on-prem server.

Workplace Innovation Platform

I am now into my 3rd decade developing on top of FileMaker and for the first time, I feel that I am in sync with–and have an essential role in–FileMaker’s strategy. FileMaker is and always has been a Workplace Innovation Platform. But there was never a common understanding even within FileMaker, Inc., never mind within the broader community, of what it was. Now there is. The time of figuring out what FileMaker is over, and the time to grow into that category is now in full swing.

We have a new community forum, new hilarious marketing videos, and even a new design on FileMaker front page. The roadmap promises more important changes coming soon. Everything is being shifted and brought into alignment with the new focus on the Workplace Innovation Platform. We even have new changes at the top jobs at FileMaker.

Changes at the Top

Dominique Groupil as CEO kept FileMaker relevant and profitable for two decades, a truly remarkable accomplishment. But even more amazing to me is the fact that he had the foresight to kick off this transformation and make sure it was on the right track before announcing his retirement and turning over the reins to Brad Freitag.

I have had the opportunity to work with Brad on the FBA Partner Council and in various other venues.  He is a good listener. He takes the time to collect and consider many viewpoints before taking action, sometimes bold action. He also has the confidence to course correct when the landscape shifts. In short, I am sure he will do an excellent job in leading the team at FileMaker, and I have high expectations for the years ahead.

The End of the Beginning

The new FileMaker 18 Platform is the world’s leading Workplace Innovation Platform used to help problem solvers address their unique business challenges. It includes great new features for developers to create, share, and integrate custom apps.

It also marks the end of the Beginning of FileMaker’s transformation. We have new features, new marketing strategy even a new management team. The transition is now well underway. Buckle up!

Future Challenges

This all great news. FileMaker needed to rise to the challenge being presented by the market today. In my opinion the challenges that lie ahead have a lot to do with developing the right language to describe what it is that Workplace Innovators have to do everyday. We have a good description of the problems people face trying to use technology to solve problems, and we now have a good set of low level capabilities like cURL, REST, WYSIWYG forms etc. So we know the goal, i.e. where we are trying to go, and we have a good tool that can get us there, but we need to make it even easier for people to pull it off.

Let me put it this way.  In 1995, I could use FileMaker 3 to build a custom information system using the just 6 concepts: Tables, Fields, Layouts, Value Lists, Scripts, and Relationships.  If you understood those six things you could build just about anything you needed at the time.

Today, I have different requirements. Things are lot more complex. I can still do everything I need to do, but it can take a too long to do it myself.  Can we find a way to “compose” new types of objects together so that we can assemble systems faster, using larger teams of people? I am not sure we can ever get back to just needing to know about 6 building blocks. But I believe there is set of modern system design patterns that we can break down, understand and recompose with FileMaker.

For example. Since version 16 FileMaker has had the capability to connect to any API and exchange data. Thats awesome! But once you start down that road you find that it is still a lot of work. We need to make that easier. I say “we” as in we the FileMaker  community and the company. It is up to all of us.

https://www.filemaker.com/learning/devcon/2019/index.html

FileMaker DevCon 2019

I intend to share more thoughts on this topic at the FileMaker DevCon in a couple of months. I am giving two talks on Workplace Innovation Platform. One will be focused on where we are right now. The other presentation will be on where I think we are headed in the next few years.

Also Jeremy Brown is giving a Training Day Session on JavaScript and Geist Interactive is also a conference sponsor. We’ll have an awesome booth. Hope to see you there.

All the best

Todd Geist
CEO, Geist Interactive

Ending a FileMaker transaction is just as important as beginning it. Your script can’t just dribble off into nothingness after the records have been created or edited or deleted. The endgame should be strong. Below I describe how Karbon and the modularfilemaker.org transaction module works. Use any of all parts of it.

As I’ve described earlier, ending the transaction is about trying to commit the changes, reverting back if there’s any error anywhere in the process. Additional clean up can be done at this time as well. Let’s look at how to end a FileMaker transaction.

End the transaction script

In Karbon, we have an “End Transaction” script. It is called after the entire transaction is completed. In our case: when the Estimate and EstimateItems have been copied to Order and OrderItems. Here’s a basic version of the script.

Here’s the basic structure:

  1. Set Error Capture to On
  2. Commit Records/Requests step
  3. Capture the error if there is one
  4. Revert back.

Try to Commit

If all goes well during the actual ‘transacting’ steps (with a portal or without), the intended changes to one or more tables have been completed. Records might have been created or data in some fields of existing records was changed and all the records are held open in the computer’s memory. We now want to push the changes to the actual file and save the changes. So we commit. We try to commit.

The explicit step to commit the changes pushes those changes to the FileMaker file itself. It saves the data. The new records now show up in the file for other users, field values have been edited, and/or records are now gone for other users.

In this step, we also release ownership of any records owned by the transaction process (the newly created or edited record and the parent estimate record). We unlock it so that others may see the changes (edits or new records) and may do their own edits.

In FileMaker, the commit step commits all the records at once; there’s no order in which they’re committed, one after another. They all commit. We can then rely on this feature to ensure that ALL the changes were made in one instant.

The error of the ways

If the commit step throws an error, we then proceed to rolling back. What are those errors? 

Well, since we’re creating records in this case, we’ll most likely get Validation Errors. We will get Validation errors if we are creating or editing records.

The rule is: If your commit would cause any Field Level Validation calculation to fail then your commit will fail.

Rollback changes

If there’s an error anywhere in the process, the transaction model allows the process to rollback the changes made. Since the changes made so far are held in the computer’s memory, any changes made are just discarded. They’re not saved to the file.

Changes that were queued up to be made can throw an error. We talked about that previously. So too can the Commit step here at the end. If there is an error anywhere, we begin the rollback.

In FileMaker we “Revert Record/Request”. This step reverts the current record and all the records changed during the transaction. In our example, if there’s an error and we “Revert” then this estimate and all its lines will not be copied into the Order Table.

ONE NOTE: If onRecordCommit is set on the starting context layout when the commit fails, the trigger will fail, and thus that script will not run.

Clean up

Once we’ve ended the FileMaker transaction, we can do other things to finish this whole process. If we’re using a context such as DBTransactions, then we can add information to the record that describes the  success or failure reason of the transaction. In Karbon and in ModularFileMaker, we have a series of custom functions that get the error and report it back in a JSON object. This information is set into a field for later reviewing.

End FileMaker transactions

Wrapping up the transaction is an important step in the process. Since we’re going to the trouble of doing the transaction anyway, we should follow through and wrap up the process. I would advise also doing the clean up. Log any information you feel it’s important to understand how the transaction committed or rolled back.

 

FileMaker transactions are essential to a well-functioning system. I haven’t stated it for awhile, so I’ll do now. If a scripted process changes (creates, edits, deletes) many records at once, a transaction is required. If a discrete entity (such as invoice and invoice line items) needs to be added or changed in some way, a database transaction is required. We’ve looked at how to do with with portals, but we can do it another way too: FileMaker transactions without portals.

Portals, as we saw in the previous post, are good for debugging and viewing, but they’re un necessary. Chris Irvine, at scalefm.com said something to a group of us chatting late-evening about transactions one day (that’s what I do in my evenings: Talk FileMaker) He said “I avoid using layout objects to do this transaction work”. That’s an interesting idea. Layout objects are user-facing things. Scripted processes should not require any layout objects to do their work. FileMaker is transactional, and through some magic, we can perform transactions from a blank layout. Let’s take a look at how to accomplish FileMaker transactions without portals.

SIDE NOTE: Chris Irvine is a smart FileMaker developer. Be sure you check out his blog posts and his speaking times at FileMaker DevCon.

Start at the very beginning

We’re back at the starting context. In our case, it’s DBTransactions layout based on that same named table occurrence. Here’s what we’ve got.

  • We are on the same DBTransactions layout.
  • The data was gathered and stored as a JSON object in a field.
  • There’s a relationship from DBTransactions and Order, and DBTransactions and OrderItem tables. They’re set to Allow creation of records via relationship”.
  • The relationship is created using a “orderID” and the primary key of the Order table. It’s a similar set up for OrderItem. These two fields in DBTransactions are visible on the layout (though they don’t have to be).

And we are ready.

Here’s the thing

The key to this transaction process is that we’re doing it the same way as with portals. We are creating records through the relationship. That’s all.  We do not traverse a portal to create or edit records. Instead we just set fields across the relationship. We can create the order record and all of the order line items records through their respective relationships without the need for a portal. Let’s pause a second and consider that for a moment. Is your mind blown? (Mine was the first time I saw this happening).

Oh. Another thing

Let’s talk about the relationship I’ve got set up first and establish some ideas about it.

You can see in the picture below my relationship to Order is set up from a field called OrderId and the primary key of the Order table.

That’s not normal. Usually we go from primary key to foreign key. But this relationship is essential to the transaction process. We want one unique record across the relevant relationship each time we’re set to create a record in that table. In a normal primary key to foreign key relationship setup, we’d have multiple related records (as the portal technique shows). We can’t have that. We tap into the power of the Magic key method to set a relationship to each unique record as it’s created. Check out Kevin Frank’s article on the magic key.

FileMaker transactions without portals

Here are our script steps.

Step 1: Create the order record.

In this step we simply set fields in the Order table with the values from, in my case here, the JSON object.

Set Field [ Order::Date ; JSONGetElement (DBTransactions::Data ; “date”) ]

As soon as the first field is set in the Order table, the primary key of that record is generated, and it pops back to the DBTransactions OrderID. The relationship between DBTransactions and the Order record is valid. Setting additional Order fields can commence.

Since a record was just created, our open record count has gone from zero to two:

 
   “OpenRecords”: 
      “DBTransactions”: 1,
      “Order”: 1
   }
}

Step 2: Create first order line item record.

This first order line item record is created very much the same. We set the value of the Order Line Item::amount field with its corresponding value in the first element of the LineItems array. Notice the set up I do before actually setting the field:

And once this field has been set, that OrderLine record’s primary key pops back to The DBTransactions table. There’s a valid relationship to an Order Line Item Record.

And guess how many records are now open. There are three open.

 
   “OpenRecords”: 
      “DBTransactions”:1 ,
      “Order”: 1,
      “OrderItem”: 1
   }
}

Step 3: Create the 2nd and remaining Line Item records.

Here’s where FileMaker transactions without portals gets crazy, so let’s pause a moment and consider what happens next. When I grab the next line item from from the $lineItems (in my example) and I go to set the OrderItem::date field, what is going to happen?

Does the 2nd order line item get created?

BUZZZ!!!

The 2nd line item does not get created because we still have a relationship from DBTransactions to the first order line item record. Setting the OrderItem::amount field with the second order line item’s information from the $lineItems overwrites the first record’s data.

So how do we create a new record in OrderItem? We clear out the DBTransactions::orderItemID field.

Woo. Wait a minute! Won’t that commit the record?

It won’t. For some magic reason, FileMaker keeps that record in its memory. We can’t see that record anymore or access it it, but we can be confident that FileMaker has that record open and uncommitted.

Now that the OrderItemId field is cleared, we can create the 2nd record across the relationship. At this point there are four open records:

 
   “OpenRecords”: 
      “DBTransactions”: 1,
      “Order”: 1,
      “OrderItem”: 2
   }
}

And we keep doing this until all records have been created across the relationship. By the end of the process using my example, I have six records open:

 
   “OpenRecords”: 
      “DBTransactions”: 1,
      “Order”: 1,
      “OrderItem”: 4
   }
}

We keep these open until we end the transaction (coming in the next post).

Transact across the relationship

It’s pretty cool how FileMaker can keep all these records open and in memory when I’ve destroyed the relationship between my starting context and the records. I was blown away when I saw this happening. I swore you needed a portal to create records. But you don’t. You can do FileMaker transactions without portals.

There are a few downsides: For one, you can’t see the records created. You know they were created. Open, but you can’t see them. Secondly. um. I can’t think of another downside. This technique eliminates the UI objects (the portals) to create the records. It’s consistent with our other actions: We can set fields without the field on the layout.

I’d encourage you to try this method. Perform FileMaker transactions without portals. Skip the objects and all that setup and use what FileMaker can do to transact the records. Karbon works this way; Karbon transacts records a lot. So give it a try.

Recently, Dave Graham and Todd Geist led a webinar about Otto, our Dev Opps tool for FileMaker. Watch the video here:

What is Otto?

Todd kicked off the meeting by describing what Developer Ops means. DevOps (as we call it) is anything that will help automate the processes you have to go through when you have to manage a FileMaker Server and FileMaker Applications.

Otto is easy to install on your FileMaker server machines.. And once on the machines, Otto provides many features for the developer:

  • Automated Data Migration
  • Proxy – API keys
  • Config settings that
  • a Developer API

These features and processes are available via your favorite browser. There are some caveats with installing Otto on server machines, and Todd clearly lays those out.

Data migration

In the webinar, Dave demonstrated how to perform quick data migrations using Otto Migrator. He showed how the developer tool does all the work for you when it comes to:

  • Pausing a file on the dev server.
  • Moving a clone of the dev file from the dev server to another server (in this case the production server).
  • Migrating the data from the old production to the clone.
  • Removing the old production file
  • Replacing the old production file with the new production file (the clone)
  • Opening the files on both the development and production servers.

He showed how easy it was to set up the routine to happen at the moment or scheduled for a later time.

Otto Migrator is a great way to reduce all the work that used to take hours into minutes. With Otto Migrator, you don’t need to plan an entire weekend for file transfer and data migration. It is all done while you get that last cup of coffee at the end of the development cycle when a file is ready to be sent to staging.

Todd then continued the webinar by going over the remaining features. Here are the highlights.

Proxy & API Keys

We have wrapped the FileMaker data api in a proxy, allowing us to add Api keys and allows us to connect directly to browsers from anywhere.

Config Settings

Many of the FileMaker Server config settings were removed from the Admin Console, putting them into the command line or the dapi. Otto makes those settings available again. Otto provides a rich, interactive user interface that shows your files’ status, your backups, and even allows you to download any backup.

Built in help

Otto has our documentation built in. There’s also a chat mechanism. Chat with Todd or Dave if there’s an issue and get help immediately!

Put it on your calendar

Todd showed off how a developer can add each schedule and completed migration to your Outlook or Google calendar. The task gives you a lot of details including whether it was successful or not and provides a link to the actual migration log in Otto.

Questions

The session ended with a standard Q & A session. Many of the participants asked great questions, and Todd and Dave took the time to answer.

 

Check out the webinar, and download Otto to try out yourself.

 

 

 

 

 

For quite a few years now, I’ve worked with JavaScript inside of FileMaker. And I’ve tried every possible way to deploy the code from an editor into the custom app. During the implementation of a web viewer widget, I’ve looked on the process with some angst or reluctance. There wasn’t a good way to deploy HTML / CSS / JavaScript into a custom app without building extra tables, fields, relationships. Or the deployment method was such that I couldn’t edit the code in a simple way. In times past, there were a lot of problems in deploying FileMaker web viewer widgets.

WidgetStudio solves the problem of deployment. The developer tool makes it a simple process to deploy a FileMaker web viewer widget that you have customized into any custom app. There’s literally no thinking about it. Click a button, and the code is deployed. Well, there’s a little more to just a button click, but honestly, not much more. Let’s take a look at the types of deployment, the implications of each type, and how easy it is to use any of these methods.

Embedded Web Viewer

Using this method, WidgetStudio actually creates a web viewer object for you and copies it to your clipboard, ready to be pasted onto a layout in your custom app. It is that simple. Watch the GIF below.

Embedded web viewers are good for simple widgets. They’re fast and easy to deploy.

Here are the details

  • I make customizations in WidgetStudio.
    • Since this widget has data coming back to FileMaker, I have the option “FileName”. I make that one “Calculated” which will use Get(FileName) calculation.
    • The widget also needs a script. I hardcoded the script name here “GetDateRange”.
  • I press the “Embedded Web Viewer Button”. The web viewer object (named “web”) is copied to my clipboard.
  • In my custom app, “JobTracking“, I went to the popover where I wanted to place the widget and pasted the object, resized it to make it fit.
  • I then created a script called “GetDateRange”. That will be called from the widget.

Pretty simple. It took me less than a minute to deploy the FileMaker web viewer widget.

The data

The data needed for this FileMaker web viewer widget is either hardcoded or a calculation. And this is found in the Let Statement variable declaration.

The data, highlighted in yellow, can be changed once deployed, or it can be adjusted in WidgetStudio.

Embedded web viewer advantages

This method is advantageous for a few reasons. The widget code is fully contained within the web viewer object. The object can be copied and pasted to other layouts, and the script that is called can be used in other places, or you can point any additional widgets to a different script.

Scripted render

So far in my work with WidgetStudio, I prefer this method. I’d rather let scripts control actions in my custom apps (because I can control the scripts themselves). WidgetStudio offers this option for all widgets.

Essentially WidgetStudio creates an entire script that does the work of compiling the code to run the widget. Watch this:

Here are the details

  • I make customizations in WidgetStudio.
    • Since this widget has data coming back to FileMaker, I have the option “FileName”. I make that one “Calculated”. The file name is gathered at run time with the Get(FileName) function.
    • The widget also needs a script. I hardcoded the script name here “GetDateRange”.
  • I press the “Scripted Rendering”. WidgetStudio copies the steps to my clipboard.
  • In my custom app, “JobTracking“, I went to the popover where I wanted to place the widget and placed a web viewer. I named that web viewer “web”.
  • I pasted the script steps in a script called “Render Date Picker”.
  • On the popover, I added an onObjectEnter trigger to run the “Render Date Picker” script.
  • I then created a script called “GetDateRange”, which will be called from the widget.

The data

As I said before, the beauty of this method is the fact it’s scripted; I can completely control the creation of the data. The data is set at the top of the script.

Though the date & time picker is simple, a complex data need requires a subscript to run. In my pivot table widget, I need a script to gather the data in the correct format and pass it back to this script. Below is a scripted render of a charting widget.

Scripted export

The scripted export method works pretty much the same as the scripted render method, with a few minor differences. This process exports your entire code to your local temp directory and then causes the web viewer object to read from that path. The created script looks like this:

The Details

In order for this method to work, you need to create a container field (invisible or off-layout) that this script can use. In line 18 of the script above, you’d set the field name there.  And again do this in line 52 of the same script.

This method is less useful since it requires a few other steps. I wouldn’t use this method at all except if I use using a widget that involved the FM WebViewer Bridge.

Solving the ‘deploy FileMaker web viewer widget’ problem

WidgetStudio’s three methods of deployment solves the problem of deploying FileMaker web viewer widgets to a custom app. There’s no rolling up of one’s sleeves to begin the arduous of creating schema. Nor are we lacking a place to edit the widget’s code and options. WidgetStudio allows us to deploy a widget in a matter of seconds.

I look back at past files I’ve created to deploy a widget. While they were good for the time and a step in the right direction, I’ll probably never go back to one of those older methods. WidgetStudio’s methods are fast and global.

Give WidgetStudio’s demo a try. Deploy the three included widgets as a test, and see how easily WidgetStudio solves the huge problem of deploying FileMaker web viewer widgets.