4 Replies Latest reply on Jan 7, 2015 11:22 AM by Mark_M

    IWP: Use of Globals

    Mark_M

      Title

      IWP: Use of Globals

      Post

      Platform: Pro Advanced 12.0v4

      Question: I’m trying to understand the use of Global Fields in IWP.

      Background:

      I’ve been using FM for about 10 years to manage an employment document process that is performed annually.   The application has gone through 2 major revisions and 1 total re-write.  The system not only prints employment documents but is used to manage and track conditions for individual employees (EE).  There are 19 different employment documents consisting of 12 very legal contracts and 7 “letters of employment”.  Teachers and administrators get “contracts” and the rest of us get “letters”.  One major difference is that contracts must be signed and return (and we track the return of the documents in FM) and letters are distributed as – ah – information only, they need not be returned.  The current EE count is about 3,000 people and once changes are locked down it take me about 2.5 days to print the 18,000 documents that go out.  (I did a test today and it would normally take about 45 minutes to print the documents for a High School, generating the PDF’s and stuffing them in a container field took less than 3-minutes.)

      Current Project:

      My boss, for a number years, has wanted to move forward with paperless employment documents and due to other none related factors I was going to have to do another major overhaul of the process.  So I’m talking this opportunity to start from the ground up and create a new system using FM 12 that will be server hosted and use IWP for delivery of the documents.  For about a month now I’ve been working on system analysis and prototyping functionality to ensure I can deliver what I’ve promised since I’ve never done any IWP work in the past.  Overall things have gone pretty well.

      Future Model:

      The application will be server based and there will be client side access for HR staff in FM Pro.  Once we do our “thing”, I’ll be scripting the generation of the documents and the PDF files will be inserted into container fields.  Employees will use a web browser (so they can do it from home and not have to have the client software).  They will login and authenticate against a server.  Once the user authenticates I use Get Application Name and determine if the login is from client software or IWP.  If the login is from client software, the opening script validates the user against an internal User Table to verify authorization.  If the login is from IWP, the script will return the EE ID and stuff that information for that session into a global field.  This field then becomes the basis for limiting record access to that EE and control on what can or cannot be done.

      Problem:

      So today I was working on opening scripts to get my prototype instance ready for some demo’s later this month.  The opening script clears the global fields by setting them to “” and then later steps populate the empty fields (the fields are also set to “” by the closing script).  I set up a temp web page where I would input the EE ID just as a placeholder to simulate the EE ID being returned by the external source.  Once the EE ID was in place additional custom information would be pulled from an internal User Table that consists of a limited number of users: HR Staff and Supervisory personnel.  Speaking strictly from an IWP standpoint, once the EE ID is returned then the User Table determines if the individual is a “DEPT” user, if so they have the ability to download a department report of the status of their subordinates so they go to a layout that gives them a choice of how to proceed.  If the individual does not have the “DEPT” flag, then they are taken to a layout where they can review employment documents and if it is a “contract” accepts or declines the contract and the electronic signature is captured.  Only HR Staff will have the shortcut to the system, but even if someone else tries to login, the login is verified against the User Table for access so if they don’t have the correct credentials they are kicked out of the system.

      So today I spent most of the day trying to use a Temporary Page (it will go away in production) to input the EE ID and then (via a button) I fired off the next script to retrieve User ID and Access Level, but I couldn’t seem to get it to work.

      So here is the general idea:

             
      • 1.  IWP opens an instance of the database.
      •      
      • 2.  Test for IWP login in the Master Opening Script.
      •      
      • 3.  If it’s an IWP login go to the Temp Web Page.  (Script ends)
      •      
      • 4.  Input EE ID and Organization ID (Org ID) into a text field.  Click a “Continue” button which activates Perform Script step to fire a different script to complete the IWP login process.
      •      
      • 5.  Based on the EE ID, retrieve User Name and Access level from the User Table.
      •      
      • 6.  If Access level <> “DEPT” go to regular landing page.  If Access level = “DEPT” take the use to the Department Head Access Page.  (The difference is the Dept Head page has an extra link to download a dept report.   

      Attempts:

      1.  In the user table the key is EEID+ORGID to be unique (“12345-020”).  So I tried taking the EE ID and Org ID and used a calculation field to create 12345-020 then used that as a basis for a join from my Global Table to the User Table.  Didn’t work.

      2.  I removed the calculation and just converted Global User Key into a global text field.  Then in a script set I would Set Field the Global User Key field to the value “12345+020”.  The Global Key then being part of the joint to the User Table Key.  Didn’t work.

      3.  I finally got a system to work, but only on the client side.  So right now I’ve disabled the clear global steps in the open and closing scripts, I populate the fields on the client side (the scripts work there) and then close the application so the globals persist.  Then I open the client.  Once the client is reopened, you can open the IWP instance with the variables present from the last time the client was closed.

       

      ****************************************************

      I guess I’m looking for one big thing:

      Confirmation that once prototyping is done and it’s ready to move to next level (external server authentication) that I will be able to grab the information from the external server and put it into a global field when IWP launches, grab the additional information as needed from the User Table and can use these fields in navigation control, find limits, etc. in IWP.  Or am I barking up the wrong tree because globals don’t work in IWP?

      As I said, I've not used IWP before so I'm on a learning curve when compared to what can be done in the FM client.

       

      >>>> 

        • 1. Re: IWP: Use of Globals
          philmodjunk

          "didn't work" is a bit vague. A description of exactly how this failed and a look at the exact script might reveal the issue. (You do know that many script steps are not compatible with IWP?)

          As far as I know global fields work in IWP just as they do in client systems of a hosted database.

          PS. there's no need to clear global fields when you close the file. The values in global fields are not retained in clients (IWP or otherwise) of a hosted database, the field values revert to the values last set to these fields on a host or via a scheduled script.

          • 2. Re: IWP: Use of Globals
            Mark_M

            >

            Set Field [tblGlobalWeb:;gbl_User_Key; tblGlobelWeb::gblUser_EE_ID & "-" & tblGlobelWeb::gblUser_Org_ID]

            Set Field [tblGlobalWeb:;gbl_User_Access; tblUserWeb::User_Access] (when Global and User Tables are jointed on a unique key)

            Both resulted in an empty field remaining empty.

             

            laugh

            Ya, I know about not needing to empty the globals, Just a habit picked up from some prior programming classes about 15 years ago.

            laugh

             

            >>>>

             

             

            • 3. Re: IWP: Use of Globals
              philmodjunk

              Global fields are accessible from any layout in the file regardless of what relationships have been defined.

              First, verify that the two target fields are truly defined in manage | Database as fields with global storage.

              Then, I'd set up a way to track the value of all fields referenced in your script at each step of the way. Obviously, you can't use the debugger to test what is happening when a web client runs this script, so you would need to set up some additional fields on a test layout and have your script use set field to copy the values of these fields to those "log fields" so that you can run the script and then check the fields to see where this fails exactly.

              I haven't done this in IWP, but the following method works well in FM GO and I see no reason why it wouldn't work here.

              I define a global text field and then "log" the values of any fields or variables that I am tracking like this:

              Set Field [ Globals::gValueLog ; List ( Globals::gValueLog ; "Step 1 | " & Table::Field ) ]

              I can then run the script once, then change to a layout that shows this field and check the values logged in the field. The "Step 1 | " text is text that I change in each place I insert that step so that I can correlate the logged value with the point in the script where that value was logged.

              • 4. Re: IWP: Use of Globals
                Mark_M

                >

                Thanks Phil that sounds interesting and I'll give it a try.  Basically setup a Log Field and then append each steps action and results to the log.

                Ya, once you get used to using the Debugger and Data Viewer to step through a script it makes it uncomfortable to work with scripts in IWP that you can't really track step by step.

                 

                >>>>