Tweet
Exporting, importing and managing APPS
The delineation what one does in NAB, NAB Import and Portal Admin - Apps feels a little scattered. Intuitively I want to go to Portal Admin - Apps to import an app. Portal Admin - Apps feels more like Work-With-Apps to me
1. Why can I not import and export apps from Portal Admin?
2. Why can I only export NAB apps and not Web Page (URL) apps from one instance to another?
3. NAB - Apps - row menu option "Share"... what is that supposed to do? It launches an empty Outlook email window with Subject "&body=" and that's it...
4. Portal Admin - Apps. That screen needs a lot more attributes. I've got a ton of apps there and we're only just getting started. Finding an app in Portal Admin - Apps is way too hard. Why can't I use the Tags in Portal Admin? Or filter on Category? I know the Tags are only "within NAB", but that's my point: why can't they travel up the stack and stay with the apps?
5. In NAB, I can edit an existing Data Source, save it and at that time I can change the name, description and even the Tags (btw, that Tags bar in that save popup doesn't have a header and if you do not have any tags yet all you see is an empty grey bar and it's not very clear that's for tags. Recommend a label be added above that grey tags field).
I can also edit a Widget again and again, and each time I hit save I get a pop up where I can enter/edit the name and the description and also the tags This pop-up is a little different from the one in Edit Data Source. Tags also does not have a label here.
So why can I not edit the name, description and tags for apps in NAB during save the same way I can with data sources and widgets??
What would also be nice is if all these save popups in Widgets and DS would have title bars on them telling me what I am saving. Yes, I know, it's sitting on top of a Edit Widget or Edit Data Source window (which is greyed out) but it would be neat if it said SAVE WIDGET or SAVE DATASOURCE in these save popups). In NAB-Miscellaneous-Tags, that pop-up has a header with the Data Source or Widget icon + its name -- at least I can tell from that icon what kind of animal I am changing the tags on.
6. I create a new NAB app. When I save it, I can only give it a name, not a description. Which is weird because I can give my DSs and Widgets names and descriptions. The only way that I know to put a description on an app is going to Portal Admin-Apps and do it there. If I then go back to NAB, my app still does not show the description I just put on it. Shows blank. When I export my app, I get a pop-up listing my app, widgets and DS's and they all have descriptions... except the app. After exporting it, the app shows the description in the target instance in Portal Admin - Apps, but not in NAB. Apps never seem to have descriptions in NAB. If you don't remember to put a description on the app before exporting it, it shows description "Nitro App" in the target instance.
7. Can we get row menu option in portal apps to Launch the app? Not a high pty but would just be handy for us administrator types
8. Can we get a refresh button on Portal Admin - Apps screen?
9. In NAB import there are 3 tabs, Data Sources, Widgets and Apps.
By and large we just export whole apps and with that come their data sources and widgets. Very rarely, if ever, do we export just data sources or widgets from one instance to another, but I do appreciate having the option to do so. We develop apps in the DEV instance and then port the entire thing over to the QA instance and finally to PROD. I do end up with some Data Sources and Widgets in NAB import but that is mostly the result of people not paying attention what row they are on when they are in NAB, Apps having their app "exploded" into app, widgets and data sources and then selecting Export on the wrong thing.
But anyway, my point is about all the rows in the Apps tab in NAB Import. They don't go away after I finish importing an app. I get why that is, but NAB Import is becoming a huge pigsty. Nobody ever clicks the X after importing an app. There are only 2 columns, Save File name and Description. And that Description there is not the app description at all, it's the app name. Actually, what I think it really is is the TEXT on the SAVF object, but when I export an app, Valence takes the App name and uses that as the text on the SAVF object for the exported app and thus, if I am in NAB Import - Apps, the description there is the in fact app name. It would be better if the column header there said Name or App Name instead of Description because apps have a Name and a Description both so calling that column Description but putting the app name there is misleading and confusing.
What's not helping me with the pigsty that NAB import has become is that I have so few attributes to work with there. Yes, I know, Valence just dumps the content of VVEXPORT library there so what I see on the screen is SAVF object name and text of the SAVF and that's it. I have 50+ rows there and 12 of them say "Custodian Maintenance". I have no idea which one to use! If I grab the wrong one I am importing an outdated app. If I do not jot down the name of the SAVF that was created when I exported the app in the from-instance, I have no clue which one to import. I have no idea when each SAVF listed in NAB Import was created nor do I know which instance it came from or who created it. At a minimum it would be nice if the date/time the SAVF was created is there as well as the user who created it, both of which are available:
SELECT OBJNAME, OBJDEFINER, OBJCREATED, OBJTEXT
FROM TABLE(OBJECT_STATISTICS('VVEXPORT', '*FILE')) A
ORDER BY OBJCREATED DESC
At least then I can sort/filter on my name and the date and have a much better chance of picking the right SAVF to import.
NAB import is only needed when you export to a SAVF. If you export directly to an instance, you don't get a SAVF and you do not need to do the NAB import thing.
I do not recommend people use the export-to-SAVF option. If I need to distribute an app from DEV to the QA and SYSTEST instances on the same machine, just do export-to-instance twice. Export-to-Instance is slicker than whale snot. When exporting something to a different machine though (like, PROD), you don't have a choice.
I think we need to start thinking about a VVEXPORT file instead of just relying on the content of VVEXPORT library, which is a "shared" library. The VVEXPORT file should have additional attributes about each app (or datasource or widget) that was exported. It should live in the VVEXPORT library. NAB Import should still only show the SAVFs that exist in library VVEXPORT, but it can now pull additional attributes for those SAVFs from the VVEXPORT file, chiefly the instance the app came from, which is absolutely critical.
10. NAB export to instance often hangs. Errors in the CGI joblog:
Referential constraint violation on member VVAPPS.
Cause . . . . . : The operation being performed on member VVAPPS file VVAPP
in library SPACESAND failed. Constraint Q_VVDEV52_VVAPPGRPS_VVAPPID_00001
prevents record number 60 from being deleted or updated in member VVAPPS of
parent file VVAPPS in library SPACESAND because a matching key value exists
in member VVAPPGRPS of dependent file VVAPPGRPS in library SPACESAND. The
constraint rule is 1. The constraint rules are:
1 -- *RESTRICT
Referential constraint violation on member VVAPPS.
Delete prevented by referential constraint
Q_VVDEV52_VVAPPGRPS_VVAPPID_00001 in SPACESAND.
Duplicate record key in member VVAPPS.
But mostly what seems to be causing the hang is this:
Not authorized to object VVAUTHAPPS in QTEMP type *FILE.
When I killed that CGI job and did it again, it worked. When I exported that same app a second time right after that, it hung again on the exact same error. I then tried exporting another app and the same thing happened. Hung again, same error messages. Basically, exporting apps more than once hitting the same CGI job causes it to spin and hang. It seems that something is being left behind in the CGI's QTEMP library that I do not have authority to the second time, even though I was the one who created that object in QTEMP the first time
Overall my impression with Apps (not critique, just my observations) is that it all works well enough in smaller environments; instances with fewer than 50 apps. Get much larger than that and things don't scale well. The portal becomes unmanageable -- already noted in previous posts. Portal Admin has some opportunities as well as security holes, also reported in the past. Finding, managing, maintaining and distributing Apps is now becoming a bit unmanageable as well. Other areas that need some attention to improve scaling include:
* Larger number of apps running in the same Apache instance. Slow running apps causing the instance to run out of CGI threads (which are single-threaded) resulting in Denial of Service
* Instance Management and DEVOPS. In a traditional green screen development environment, developers have developer libraries, check out programs and files, promote stuff up the stack from their DEVLIB to TEST to PROD using the CMS. There is "separation" during development because people work in their DEV libs. The CMS provides controls, handles locks, concurrent development and promotion.
With Valence I have 15 developers all hammering away in the same instance. I can't "check out" an app. We use Tags in NAB to emulate the concept of developer libraries in an attempt to keep things somewhat organized and find-able. We need better ways to organize and manage apps in NAB. It would be nice to have more attributes in NAB to organize apps in the making. Developer USERID would be a great addition. We also need a better way to separate apps in development from apps that are live, or in test. Right now they are all in One Big Pile in NAB and the only thing we have to manage things are tags. The tags are absolutely crucial. If people don't add tags to their stuff and religiously follow established Tag Conventions (application subsystem like WN Windows,. AP Accounts Payable etc.), and their User ID, it's impossible for others (peers, managers, administrators and even themselves) to find their stuff. I also need much, much better controls around who can promote stuff to PROD and we really need that security hole in Portal Admin - Edit Groups fixed that I have reported. Anyone allowed to Edit Groups can make himself an administrator and then maintain categories, groups, access to apps and (EEEK!) Portal Admin Settings.
* Aside from this Forum... is there a CAB -- Customer Advisory Board? That might be something worth considering. Could be totally virtual but it would be nice to get some other CNX customers on a call once in a while and discuss certain things.
Final but very important note at the end of this long dissertation....
I can imagine that getting hammered with feedback, issues and opportunities for improvement through this forum can feel like getting bashed and hammered at times. Nothing is further from the truth. We love Valence, NAB and everyone at CNX. You guys all ROCK. Your responsiveness is incredible. At times I wonder how you are going to keep that up. Please rest assured that any and all feedback provided is 100% intended as positive and constructive feedback, we're just trying to help improve things...
1. Why can I not import and export apps from Portal Admin?
2. Why can I only export NAB apps and not Web Page (URL) apps from one instance to another?
3. NAB - Apps - row menu option "Share"... what is that supposed to do? It launches an empty Outlook email window with Subject "&body=" and that's it...
4. Portal Admin - Apps. That screen needs a lot more attributes. I've got a ton of apps there and we're only just getting started. Finding an app in Portal Admin - Apps is way too hard. Why can't I use the Tags in Portal Admin? Or filter on Category? I know the Tags are only "within NAB", but that's my point: why can't they travel up the stack and stay with the apps?
5. In NAB, I can edit an existing Data Source, save it and at that time I can change the name, description and even the Tags (btw, that Tags bar in that save popup doesn't have a header and if you do not have any tags yet all you see is an empty grey bar and it's not very clear that's for tags. Recommend a label be added above that grey tags field).
I can also edit a Widget again and again, and each time I hit save I get a pop up where I can enter/edit the name and the description and also the tags This pop-up is a little different from the one in Edit Data Source. Tags also does not have a label here.
So why can I not edit the name, description and tags for apps in NAB during save the same way I can with data sources and widgets??
What would also be nice is if all these save popups in Widgets and DS would have title bars on them telling me what I am saving. Yes, I know, it's sitting on top of a Edit Widget or Edit Data Source window (which is greyed out) but it would be neat if it said SAVE WIDGET or SAVE DATASOURCE in these save popups). In NAB-Miscellaneous-Tags, that pop-up has a header with the Data Source or Widget icon + its name -- at least I can tell from that icon what kind of animal I am changing the tags on.
6. I create a new NAB app. When I save it, I can only give it a name, not a description. Which is weird because I can give my DSs and Widgets names and descriptions. The only way that I know to put a description on an app is going to Portal Admin-Apps and do it there. If I then go back to NAB, my app still does not show the description I just put on it. Shows blank. When I export my app, I get a pop-up listing my app, widgets and DS's and they all have descriptions... except the app. After exporting it, the app shows the description in the target instance in Portal Admin - Apps, but not in NAB. Apps never seem to have descriptions in NAB. If you don't remember to put a description on the app before exporting it, it shows description "Nitro App" in the target instance.
7. Can we get row menu option in portal apps to Launch the app? Not a high pty but would just be handy for us administrator types
8. Can we get a refresh button on Portal Admin - Apps screen?
9. In NAB import there are 3 tabs, Data Sources, Widgets and Apps.
By and large we just export whole apps and with that come their data sources and widgets. Very rarely, if ever, do we export just data sources or widgets from one instance to another, but I do appreciate having the option to do so. We develop apps in the DEV instance and then port the entire thing over to the QA instance and finally to PROD. I do end up with some Data Sources and Widgets in NAB import but that is mostly the result of people not paying attention what row they are on when they are in NAB, Apps having their app "exploded" into app, widgets and data sources and then selecting Export on the wrong thing.
But anyway, my point is about all the rows in the Apps tab in NAB Import. They don't go away after I finish importing an app. I get why that is, but NAB Import is becoming a huge pigsty. Nobody ever clicks the X after importing an app. There are only 2 columns, Save File name and Description. And that Description there is not the app description at all, it's the app name. Actually, what I think it really is is the TEXT on the SAVF object, but when I export an app, Valence takes the App name and uses that as the text on the SAVF object for the exported app and thus, if I am in NAB Import - Apps, the description there is the in fact app name. It would be better if the column header there said Name or App Name instead of Description because apps have a Name and a Description both so calling that column Description but putting the app name there is misleading and confusing.
What's not helping me with the pigsty that NAB import has become is that I have so few attributes to work with there. Yes, I know, Valence just dumps the content of VVEXPORT library there so what I see on the screen is SAVF object name and text of the SAVF and that's it. I have 50+ rows there and 12 of them say "Custodian Maintenance". I have no idea which one to use! If I grab the wrong one I am importing an outdated app. If I do not jot down the name of the SAVF that was created when I exported the app in the from-instance, I have no clue which one to import. I have no idea when each SAVF listed in NAB Import was created nor do I know which instance it came from or who created it. At a minimum it would be nice if the date/time the SAVF was created is there as well as the user who created it, both of which are available:
SELECT OBJNAME, OBJDEFINER, OBJCREATED, OBJTEXT
FROM TABLE(OBJECT_STATISTICS('VVEXPORT', '*FILE')) A
ORDER BY OBJCREATED DESC
At least then I can sort/filter on my name and the date and have a much better chance of picking the right SAVF to import.
NAB import is only needed when you export to a SAVF. If you export directly to an instance, you don't get a SAVF and you do not need to do the NAB import thing.
I do not recommend people use the export-to-SAVF option. If I need to distribute an app from DEV to the QA and SYSTEST instances on the same machine, just do export-to-instance twice. Export-to-Instance is slicker than whale snot. When exporting something to a different machine though (like, PROD), you don't have a choice.
I think we need to start thinking about a VVEXPORT file instead of just relying on the content of VVEXPORT library, which is a "shared" library. The VVEXPORT file should have additional attributes about each app (or datasource or widget) that was exported. It should live in the VVEXPORT library. NAB Import should still only show the SAVFs that exist in library VVEXPORT, but it can now pull additional attributes for those SAVFs from the VVEXPORT file, chiefly the instance the app came from, which is absolutely critical.
10. NAB export to instance often hangs. Errors in the CGI joblog:
Referential constraint violation on member VVAPPS.
Cause . . . . . : The operation being performed on member VVAPPS file VVAPP
in library SPACESAND failed. Constraint Q_VVDEV52_VVAPPGRPS_VVAPPID_00001
prevents record number 60 from being deleted or updated in member VVAPPS of
parent file VVAPPS in library SPACESAND because a matching key value exists
in member VVAPPGRPS of dependent file VVAPPGRPS in library SPACESAND. The
constraint rule is 1. The constraint rules are:
1 -- *RESTRICT
Referential constraint violation on member VVAPPS.
Delete prevented by referential constraint
Q_VVDEV52_VVAPPGRPS_VVAPPID_00001 in SPACESAND.
Duplicate record key in member VVAPPS.
But mostly what seems to be causing the hang is this:
Not authorized to object VVAUTHAPPS in QTEMP type *FILE.
When I killed that CGI job and did it again, it worked. When I exported that same app a second time right after that, it hung again on the exact same error. I then tried exporting another app and the same thing happened. Hung again, same error messages. Basically, exporting apps more than once hitting the same CGI job causes it to spin and hang. It seems that something is being left behind in the CGI's QTEMP library that I do not have authority to the second time, even though I was the one who created that object in QTEMP the first time
Overall my impression with Apps (not critique, just my observations) is that it all works well enough in smaller environments; instances with fewer than 50 apps. Get much larger than that and things don't scale well. The portal becomes unmanageable -- already noted in previous posts. Portal Admin has some opportunities as well as security holes, also reported in the past. Finding, managing, maintaining and distributing Apps is now becoming a bit unmanageable as well. Other areas that need some attention to improve scaling include:
* Larger number of apps running in the same Apache instance. Slow running apps causing the instance to run out of CGI threads (which are single-threaded) resulting in Denial of Service
* Instance Management and DEVOPS. In a traditional green screen development environment, developers have developer libraries, check out programs and files, promote stuff up the stack from their DEVLIB to TEST to PROD using the CMS. There is "separation" during development because people work in their DEV libs. The CMS provides controls, handles locks, concurrent development and promotion.
With Valence I have 15 developers all hammering away in the same instance. I can't "check out" an app. We use Tags in NAB to emulate the concept of developer libraries in an attempt to keep things somewhat organized and find-able. We need better ways to organize and manage apps in NAB. It would be nice to have more attributes in NAB to organize apps in the making. Developer USERID would be a great addition. We also need a better way to separate apps in development from apps that are live, or in test. Right now they are all in One Big Pile in NAB and the only thing we have to manage things are tags. The tags are absolutely crucial. If people don't add tags to their stuff and religiously follow established Tag Conventions (application subsystem like WN Windows,. AP Accounts Payable etc.), and their User ID, it's impossible for others (peers, managers, administrators and even themselves) to find their stuff. I also need much, much better controls around who can promote stuff to PROD and we really need that security hole in Portal Admin - Edit Groups fixed that I have reported. Anyone allowed to Edit Groups can make himself an administrator and then maintain categories, groups, access to apps and (EEEK!) Portal Admin Settings.
* Aside from this Forum... is there a CAB -- Customer Advisory Board? That might be something worth considering. Could be totally virtual but it would be nice to get some other CNX customers on a call once in a while and discuss certain things.
Final but very important note at the end of this long dissertation....
I can imagine that getting hammered with feedback, issues and opportunities for improvement through this forum can feel like getting bashed and hammered at times. Nothing is further from the truth. We love Valence, NAB and everyone at CNX. You guys all ROCK. Your responsiveness is incredible. At times I wonder how you are going to keep that up. Please rest assured that any and all feedback provided is 100% intended as positive and constructive feedback, we're just trying to help improve things...
Comment