5 Replies Latest reply on Jun 1, 2017 8:36 AM by steveoh

    Overcoming Server Cache and uploads without Port 443

    steveoh

      Good Afternoon

       

      Let me start by saying I have greatly appreciated help I have received here in the past.  As a largely self taught developer this community has helped me to learn a lot and hopefully one day I can give back in a similar way.  Thank you to all those who have given me advice and tips to help on that journey.  You're awesome.

       

      To the current matter, I've recently been working on a solution converting our current business to paperless.  To accomplish this I have a series of iPads running FMGO that I am using as customer signing platforms that also display paperwork.

       

      I've come to a problem in the course of my work and despite my best efforts have been forced to come up with dirty workarounds that, while somewhat effective, are still dirty workarounds.  Basically, my problem has to do with cache.  The iPad and the computer can display the same fields for the same record with different information.

       

      My current dirty fix is to have a field that is replaced with Get ( CurrentTimeUTCMilliseconds ) whenever changes are made on the computer.  It is also being updated on the iPad and acts as in a makeshift refresh script that forces the record to load it's current server version.  While this works and is relatively light weight, the fix does not work when creating new records or updating portals.   It's maddening.

       

      Also, in the same line of inquiry, I have need to upload PDF's for storage purposes, but doing so without port 443, which also enables web direct, is proving to be tedious.  Is there another way to upload files that can be done without opening port 443?  Currently, having that port closed means each uploaded pdf takes up to a minute, which is crippling when multiple PDF's have to be uploaded at once.

       

      For the cases of this problem, you should assume that the server settings can't be drastically altered as they have a solution hosted thereon that should not be changed.

       

      So, in summary, my two issues are:

      • Overcoming Server Cache
      • Uploading without Port 443

       

      Any suggestions or help would be greatly appreciated.

        • 1. Re: Overcoming Server Cache and uploads without Port 443
          mikebeargie

          Make sure to post separate questions as their own threads in the future please.

           

          To answer your first question, regardless of table, I ALWAYS have the following five fields:

          -Primary Key ( an incrementing serial number or auto-enter UUID )

          -Creation Account (Auto-enter creation account name)

          -Modification Account (Auto-enter modification account name)

          -Creation Timestamp (Auto-enter creation timestamp)

          -Modification Timestamp (Auto-enter modification timestamp)

           

          With those fields being auto-entered, especially with mod tstamp, I know that I will not have to manually "force" a field to update to make sure that the modification timestamp is current. All of those fields will auto-enter when either a record is created or a change is saved.

           

          However, in your case, it sounds like something else is a root cause. What I suspect is that when the iPad is sitting there looking at a record, someone on the server/desktop side or another iPad makes a change to the data, and it is not properly committed to the database. If it WAS properly committed, the iPad user viewing that record would see their screen refresh as the record was updated remotely (exception being if they were using an offline copy with some sync solution like MirrorSync on iPad).

           

          So to fix that, there's a few simple ways of doing so:

           

          1) Add a timer whenever a record is "opened". Basically a trigger for the layout in question would tell a script to run at some sort of interval that checks to see if there were any changes, and then saves the record automatically if so. This would force a commit even if the user doesn't.

          Further Reading:

          Install OnTimer Script: FileMaker Pro 15 Help

          Get(ModifiedFields) - FileMaker Pro 16 Help

          Get(RecordOpenState) - FileMaker Pro 16 Help

           

          2) Add a save button. SUPER EASY. Just make a button on your layout and assign it the "Commit Record" script step. Bonus Points, you can make a "read-only" view on your layout, then have a button that takes you to an "edit view" that requires the user to press cancel or save to return. The new FM16 Card window is amazing for this.

          FileMaker’s card window: What you need to know – MainSpring — Time to Innovate

           

          3) field level triggers. Similar to #1, but kicked off only when a user enters a field to edit something. This is not really preferred since it means adding a trigger to a lot of field objects.

           

          4) Train your users - probably should do this anyways. Do you know what actions kick off the auto-save/commit of a record in FileMaker? If so, do your users know? One good way to test is under layout settings, turn off the auto-save checkbox for a layout. Then play around to see what will actually give you the "save changes to this record?" dialog box. Note where the dialog appears, because if your users aren't doing one of those actions, they're not saving their changes. It's common for someone to make a change, leave their cursor in the field without saving, and then walk away not knowing that their change is incomplete.
          Setting the automatic record-saving option for a layout

          1 of 1 people found this helpful
          • 2. Re: Overcoming Server Cache and uploads without Port 443
            mikebeargie

            Also, in the same line of inquiry, I have need to upload PDF's for storage purposes, but doing so without port 443, which also enables web direct, is proving to be tedious. Is there another way to upload files that can be done without opening port 443? Currently, having that port closed means each uploaded pdf takes up to a minute, which is crippling when multiple PDF's have to be uploaded at once.

            This is not true, port 443 does not enable webdirect. You can turn webdirect off but still use the WPE and other services on Port 443. The only thing enabling port 443 does is require you to install a valid SSL certificate to your server so it's secure. This is a recommended practice and you should consider it.

             

            As for alternatives, Insert From URL can be used to insert a PDF into a container field, this usually functions over port 80 unless a :### port number is part of the top level domain (EG http://somesite.com:8080/somefile.pdf)

            Insert From URL - FileMaker Pro 15 Help

             

            However again in this case, I suspect your method for uploading PDFs. How are you uploading them, and from what device? Does your server have the "Use SSL for connections" checkbox set?

            1 of 1 people found this helpful
            • 3. Re: Overcoming Server Cache and uploads without Port 443
              steveoh

              Firstl, thank you for your reply!

              Make sure to post separate questions as their own threads in the future please.

              Will do, sorry about that.  I was under perhaps false impression that one server related fix might correct both.  A fools hope perhaps, but alas.

               

              To answer your first question, regardless of table, I ALWAYS have the following five fields:

              -Primary Key ( an incrementing serial number or auto-enter UUID )

              -Creation Account (Auto-enter creation account name)

              -Modification Account (Auto-enter modification account name)

              -Creation Timestamp (Auto-enter creation timestamp)

              -Modification Timestamp (Auto-enter modification timestamp)

              I have all of those things, but I've used the "Get ( CurrentTimeUTCMilliseconds )" thing in leu of a modification stamp as the modification stamp was not overcoming the problem.  By forcing both devices to update the field I found it forced both to load the existing data in the other fields.  Again, a dirty workaround.  As you said, this isn't the issue, but a symptom of it.

              1) Add a timer whenever a record is "opened". Basically a trigger for the layout in question would tell a script to run at some sort of interval that checks to see if there were any changes, and then saves the record automatically if so. This would force a commit even if the user doesn't.

              Further Reading:

              Install OnTimer Script: FileMaker Pro 15 Help

              Get(ModifiedFields) - FileMaker Pro 16 Help

              Get(RecordOpenState) - FileMaker Pro 16 Help

               

              I use OnTimer Scripts heavily with the iPad.  I suppose it is a good idea to outline the general function between the iPad and the Computer.  Essentially, I have the Computer navigating between different pages and updating a field for the current Layout so that the iPad can go to that layout following an on timer script.  The iPad is thereby used as a display layout for the customer as well as being a platform to sign acknowledgements. 

               

              The primary issue is that when I would update the 'CurrentLayout' field, it would show as the previous layout on the iPad (or the next layout if I had gone back a page).  I tried a number of things from Commit Records overwriting cache (all forms of commit) and refresh window to no avail.  The only thing I found to work was my 'fix' as essentially when the computer made a change to the layout it would update the "Get ( CurrentTimeUTCMilliseconds )" field.  Having read the , I'm honestly not sure of the benefits of using Get(ModifiedFields) and Get(RecordOpenState) in this instance as opposed to a blanket approach, but am open to suggestion.

              2) Add a save button. SUPER EASY. Just make a button on your layout and assign it the "Commit Record" script step. Bonus Points, you can make a "read-only" view on your layout, then have a button that takes you to an "edit view" that requires the user to press cancel or save to return. The new FM16 Card window is amazing for this.

              FileMaker’s card window: What you need to know – MainSpring — Time to Innovate

              So it appears I overlooked adding a commit records when creating new records step.  This would explain why they didn't show up and makes me look the fool for not thinking of that.  Thanks for your suggestion here. 

              3) field level triggers. Similar to #1, but kicked off only when a user enters a field to edit something. This is not really preferred since it means adding a trigger to a lot of field objects.

              I use these extensively.

              4) Train your users - probably should do this anyways. Do you know what actions kick off the auto-save/commit of a record in FileMaker? If so, do your users know? One good way to test is under layout settings, turn off the auto-save checkbox for a layout. Then play around to see what will actually give you the "save changes to this record?" dialog box. Note where the dialog appears, because if your users aren't doing one of those actions, they're not saving their changes. It's common for someone to make a change, leave their cursor in the field without saving, and then walk away not knowing that their change is incomplete.

              Setting the automatic record-saving option for a layout

              Not a concern.

              • 4. Re: Overcoming Server Cache and uploads without Port 443
                steveoh

                Mike Beargie wrote:

                 

                Also, in the same line of inquiry, I have need to upload PDF's for storage purposes, but doing so without port 443, which also enables web direct, is proving to be tedious. Is there another way to upload files that can be done without opening port 443? Currently, having that port closed means each uploaded pdf takes up to a minute, which is crippling when multiple PDF's have to be uploaded at once.

                This is not true, port 443 does not enable webdirect. You can turn webdirect off but still use the WPE and other services on Port 443. The only thing enabling port 443 does is require you to install a valid SSL certificate to your server so it's secure. This is a recommended practice and you should consider it.

                I was running off of false information then.  I will look into the matter and update my comments accordingly.  Thank you for the clarification

                As for alternatives, Insert From URL can be used to insert a PDF into a container field, this usually functions over port 80 unless a :### port number is part of the top level domain (EG http://somesite.com:8080/somefile.pdf)

                Insert From URL - FileMaker Pro 15 Help

                Inserting from URL works quickly, but it does not allow for interactive content, which is what I require unfortunately.  If there is a way to do it with that result I would use it in a heartbeat.

                However again in this case, I suspect your method for uploading PDFs. How are you uploading them, and from what device? Does your server have the "Use SSL for connections" checkbox set?

                My method for uploading PDF's is this:

                Set Variable [$Path ; Value: Get ( TemporaryPath ) & Get ( LayoutName ) & ".pdf" ]

                Save Records as PDF [ Restore ; with dialog Off ; "$Path" ; Current Record ]

                ...

                Other steps

                Insert File [ Insert ; Display Content ; Compress when possible ; Table::Field ; "$Path" ]  (have also tried Insert PDF to the same result)

                This is performed by the computer upon submitting the documents.  I am not sure about the SSL portion, but will look further into that.

                • 5. Re: Overcoming Server Cache and uploads without Port 443
                  steveoh

                  I've since found that using Base64Decode I can turn a non interactive file into an interactive one.  That means that InsertFromUrl is the final fix that I needed without opening port 443!  Thank you sir for your comments and help!