7 Replies Latest reply: May 29, 2016 6:37 PM by Daniel Jenkins RSS

    set nprinting wildcard source like .\*.qvw ?

    Steve Lord

      Hi, Is there a way to set nprinting source file as a wildcard like .\*.qvw ? (I tried that and it rejected the *.)

       

      similar but not the same:

      I was told how to do a relative filepath to output files to wherever the nsq happens to be sitting, by making the default output folder simply a period (,).  One of my colleagues realized that if we can make the source filepath a relative/wildcard like .\*.qvw, .\ we could make one nsq to run whichever qlikview is in the folder with it, however it's named.

        • Re: set nprinting wildcard source like .\*.qvw ?
          Daniel Jenkins

          Hi Steve,

           

          I strongly recommend that you make use of NPrinting Environment Variables: How to Use Environment Variables

           

          This way you can keep the source file names static (no need for wildcard characters) but still have different copies with different data in different folders. To swap between the sources simply edit the environment variable value.

           

          For example let's say you have C:\Temp\Source\Sample.qvw that contains data for all countries and C:\Temp\Source2\Sample.qvw that contains data only for Canada. Notice that the file names are the same but the paths are different. You can create an environment variable like this:

          Use this environment variable in the Connection path:

          Build your reports as usual.

           

           

          If you want to change the source to C:\Temp\Source2\Sample.qvw, simply edit the value of the environment variable NPintSource.

          Preview the same report

           

          HTH - Daniel.

            • Re: set nprinting wildcard source like .\*.qvw ?
              Daniel Jenkins

              By the way you can use your System Environment variables instead if you don't want to make changes to the NSQ.

              In your NSQ for the Connection:

              Note that any change to your System Env. Variables will only be picked up if you close NPrinting completely (not just the NSQ) and then open it again. This should not be a problem as you are using PowerShell which I assume opens a new instance of NPrinting every time.

               

              HTH - Daniel

                • Re: set nprinting wildcard source like .\*.qvw ?
                  Steve Lord

                  Thanks Dan, we've looked at environmental variables and appreciate how the one variable can update the many filepaths in the nsq with one change up at the variable value level.  However, the need to change the variable or setup multiple variables, leads to the need for multiple nsqs or a powershell that can change the variable for us.  We're trying to take manual change/setup work out to support longterm scalability of maintenance efforts..  And there's no powershell code we're aware of for changing variables.  We truly are interested in doing a wildcard filename on a relative filepath for the source qvw, so the nsq can just run whichever qvw it is sitting next to.

                   

                  We're looking into some other powershell code to change qvw file names to something generic for nprinting, then change them back now as an alternative.  So nprinting can just have the one generic qvw name for its source.  If there's a wildcard we could use for the filenames though, that'd be much appreciated.  Thanks

                    • Re: set nprinting wildcard source like .\*.qvw ?
                      Daniel Jenkins

                      Hi Steve,

                       

                      Using wildcards for source filenames in my opinion is not a good idea. My reasoning is that if you have multiple QVW files in the specified folder (say C:\Temp\Source2\*.qvw) which one does NPrinting pick up? How would the cache be generated? What if another one is added or one deleted? What if the structure changes? What would NPrinting call each new connection and how would you reference them individually when creating reports? What about multi-doc....etc., etc. In my opinion the best way to manage sources is to create individual unique Connections for each QVW and build the object list for each. If you want to swap out or point to a copy of the QVW with the exact same structure but different data then Environment Variables allow you to do that.

                       

                      You can use the .NET Framework and the SetEnvironmentVariable method to create/change Machine level environment variables. For example, to create or modify the NPSource variable to hold a value of C:\Temp\Source3 I would use: [Environment]::SetEnvironmentVariable("NPSource", "C:\Temp\Source3", "Machine")

                       

                      HTH - Daniel.

                        • Re: set nprinting wildcard source like .\*.qvw ?
                          Steve Lord

                          Thanks, for this process there would only be the one processing qlikview in the folder with nprinting.  The qlikviews themselves are all scattered across various client-specific processing folders, 1 in each of those folders.  It is the case for all of these that nprinting will need only reload the qvw, grab TB01, and put the csv somewhere.  Powershell actually grabs files from the ftp, puts them under the qlikview, tells nprinting to run the qlikview, picks up the file nprinting saved, renames it and puts it somewhere else for another automated process to upload.  (Colleague has the powershell cycling through variables to identify files based on a complex array of conditions, so the nprinting can be that simple.)

                           

                          Manager actually has an idea to just park the nsq next to the powershell on the server, let powershell fetch the qvw and raw file, rename the qvw to 'processing.qvw', tell nprinting to run the job whose source is processing.qvw, then powershell switch the qvw name back, change the processed csv file to the desired name, and put the qvw and new csv back where it wants them.  Powershell is governing an assembly line at this point, and nprinting is one of the robot arms with a very specific task.  For this particular team.

                           

                          There is another team that I am developing actual nprinting reports for - grabbing charts and graphs and putting them on powerpoints and such.  For them, we'd have the same layout for most clients, and the reporting qlikviews contain all client data, so I'd just need to cycle through client filters on the one set of qlikviews to output each client's report to their folder.  I have an idea I can make one nprinting job that kicks out 20 reports for me.   I'm not a powershell guru myself but the reporting data comes from the database so I just need qvmc and nprinting and maybe one line of powershell code to automate that once I'm sure of it.

                           

                          Edit: and one reason we're leaning on powershell is that nprinting 16 server requires us to be administrators in the server environment (qvmc does not) and security people don't hand that kind of access out lightly (at all).  We're told nprinting 17 doesn't have the same restraint but has fires being put out right now, so we're cruising on nprinting 16 designer and powershells for the moment.  (I know someone else was interested in running nprinting jobs from qvmc so they'd be more seamless in their timing even.)