Just want to share my expirience with NP 17. X.X. and join this conversation as it may help me understand where NPrinting is heading.
I started using and developing NPrinting applications for customers when NPrinting was at version 12.X.X - so it has been a while. In this time i used to use 2 environments like you said and used to copy nsq files & templates between dev & prod.
It took me quite a lot of time to convert to new world of NPrinting 17 and i completly had to chaneg my habits and customs. I would compare this with development between QlikView and QlikSense. With QlikView usually you would develop an application on desktop and then migrate it to test server and then after UAT you would put it into production. Ask yourself a question how does it work with QlikSense. In reality (probably) you go usually to production environment where you build application in "My Work" area, then you publish it let say to "UAT stream" and then you publish it to "Production stream", but you are dooing everything on one box, in production environment. This is the case with 95 % of my current clients.
With NPrinting 17 is similar. You go to production environment and you develop in there. My practice is to do a repository backup before modifying existing reports (just in case i brake something). If i am developing new thing i am not worried to much about production stuff as it is working properly anyway and i can just focus on my work which is structured like this:
- NPrinting Application
- Reports (It is actualy separate tab in NPrinting but logicly it sits under separate apps)
- Admin & Other things
That structure forces you to keep everything clean and neat.
You do not have nsq files which you have to copy, or template folders etc (everything is held in repository and is assigned to apps and other entities).
Like i said - everything sits in repository. Still - there are actualy real XLS, PPTX etc templates however, but they are managed in repository.
I agree that it is not ideal solution and having possibility of 2 environments sound safer, however if you think of how much different NPrinting 17 is from 16 and earlier versions you will relize that it is not that simple anymore, and i am struggling to think how possibly it could work without issues.
Think of it as of DB. Can you update transactional table from Dev DB without updating other tables? probably not?
The same applies to NPrinting 17. You can have 2 environments but you will always have to overwrite whole repository to migrate. The only bit i can think of really (and is is missing now) is posibility of exporting an App in NPrinting with all linked entities like Connection, Filters, Reports - similar to nsq. This is a question to people you mentioned in your post.
Last thing is that once you start developing in NPrinting 17.x.x you will notice that you have to keep your work cleaner and more structured, so i would not worry to much about extra stuff you will have in Dev environment, but would force and introducie policies and practices when developing.
Ps. I think NPrinting 17 is a great toll with one issue - it is terrible when you need to refresh metadata ( that is when 99% of my issues were sitting) but once you are past this step and you actualy start working with cashed metadata, filters, templates and console - it is very easy. I also have to admit that having a posibility of assigning roles to users and giving them certain priviliges gives a lot of flexibility as well as it is much easier to push some work on users. Subscriptions and News Stand is another great feature - I really appreciate having it there as a out of the box reporting portal.
- Features 80% happy- currently lacking cycling and HTML embeded reports in email, and kill task feature!, Recipient import is currently supported only from XLS, No Job/Task concept!!
- Self Service 110% happy- once you create templates - you can let people decide how they will for example filter reports (reusing the same template) - took a lot of work from my shoulders
- Fucntionality 110% happy - NewsStand, Subscriptions, Qlik Sense Hub as destination, On Demand reporting with QlikView -all great and
- Stability: 50-50% - once it works, then it works, once you have an issue with it, then usually i had to reboot server (not great) to get it fixed. Production environments are in my case working fine without issues, and you can still chabge filters, create new templates etc. The stability issue accured usualy during "Generate Metadata process".
Hope this will give you little bit of light on where you are headed. I am looking forward to seeing how this converstion will follow.
Thanks so much for sharing your experience. I am sure it will be useful for many on this site. I do agree that the Portal and the New Stand will make administration easier and more self service for the end users.
What have you done to train your people on how to use / develop in 17? We have many QV developers now that can create reports in 16.5 and it would be helpful if there was a standardized 1 or 2 day training class that we could either buy or hire someone to deliver to get us all up to speed quickly. Hoping a Partner or consultant is offering this service and can respond here on this post.
regarding the possibility to migrate content from dev to prod what I can tell you is that we are currently working on it (I mean we are actually implementing the code ).
The first step will be to enable the migration of a single report (with filters and connection informations).
Of course the final step will be to enable the migration of an entire App.
We plan to release this feature (report migration) within the September release but, as soon as we have a first working version we want to release a beta/tech preview in order to collect feedbacks and issues to be solved into the GA version.
Hope this helps.
We are in the processing of getting 17 June release set up for On-Demand printing by our users. We work with a Dev, QA ,and PROD environment set up where developers are only allowed to work on Dev server and request admin to migrate to QA and PROD which doesn't seem feasible in the current version without migrating the entire repository which could contain items that are still in process and shouldn't be moved to QA/PROD.
I understand from your comments above that in Sept release, there will be the ability to migrate an NP app and reports. Can you provide any more information about how this will work in the new release? One question I have is how we will change the connection path as the app is migrated up through the environments.
Luckily i did not have to train people. We worked it all out together and agreed on common standards. In terms of clients enablement - this is an unknow area as you never know what your client will come up with. With a product changing as fast as curently NPrinting is, we did not pay efforts to create manuals or deliver proper training.
- NPrinting Application