PUBLISHING/INTEGRATION of Javascript and Database Thing Services

OldGoat · ‎Apr 08, 2021

We have DEV, TEST, and PROD environments. The DEV environment is wide open for developers to make their changes. However the TEST and PROD environments reside behind firewalls which only administrators can access. In order to publish changes, you have to import the ENTIRE Javascript or Database thing up to TEST and PROD. There are many problems with this, including the possibility of inadvertently publishing code that is in development and not ready for publishing...this has already caused massive problems on our production applications. We need the ability to publish individual services, and the ability to modify services does not need to be blocked for only administrators. If a role existed for PUBLISHERS, the services could be modified by authorized personnel. As it is now, that falls on the shoulders of the server administrators, who have absolutely no clue about our application requirements. I'd be glad to talk to someone about this...I know I'm not explaining it well here.

olivierlp · ‎Aug 16, 2021

"Thanks for sending your idea but I'd like to understand a bit more about it.
1. In part, is this about setting up Thingworx permissions which seems like your production admins don’t know how to do. So a preconfigured PUBLISHERS role would help you achieve that?
2. For ability to publish individual services, you could partly address this with modelling. If you want this capability then isolate those services into their own ThingShapes which can be published independently. Publishing a partial thing isn’t going to happen and would introduce more problems than it solves probably since those services would be referring to other entities which would be missing.
3. For the ability to modify services, seems like it is related to the above PUBLISHERS role. One thing you can do is to use LDAP or MS Active Directory which end user admins are familiar with to manage roles, users etc. and they can define their own PUBLISHER role from dev side and import to production?"

OldGoat · ‎Oct 19, 2021

Olivierlp,

Thank you for reaching out. I will try to answer your questions as best as I can.

I am sure you are painfully familiar with how the Govt. structures their computing environments. They have very strict cybersecurity measures and procedures published as DOD and DISA Security Technical Implementation Guides (STIGs) which dictate when, how, and by whom each and every operation is performed. While the addition of a PUBLISHER role is a GREAT idea, it would still get locked down under the role of the server administrator and it still won't help us. Plus the addition of using LDAP / AD for additional roles would cause us to run afoul of even more cybersecurity STIG limitations and headaches. But that wasn't the real point of my post. It deals primarily with the publishing of "THINGS".

I agree that having separate "THINGS" for each application is the correct approach. Our team is talking about that approach and we will most likely adopt that approach with the next new application. It doesn't help with our current applicatons, and we simply don't have the time to change them...it would be easier if you could export a block of services and import them into a new thing...but you already said that "WON'T" happen...LOL! This does highlight another major integration issue - there is no quick and easy way to reveal which services are being used by what applications...in fact, that is a major problem with all entities. I realize that adding projects and tags handles that, but by looking at the listing, that info is not exposed until you open each individual entity. And what if you mis-tag one or forget to tag it or add it to a project? There is no validation service to enforce their use. With a growing catalog, that is a massive undertaking. When we had just two developers, it wasn't too big a problem. But our team has grown.

Exporting a Javascript Thing for publishing is not a major problem except that any services in development get moved and installed...this is another integration issue. Would it be possible to have an "enable/disable" checkbox or switch in each service like you have in schedulers? I don't know...just a thought.

Any "THING" that has an embedded userid/password is the real problem, however. Because we are lowly developers (in the server owners' eyes), we don't know what the passwords are...and according to the STIGs, we aren't allowed to know. If we export a database thing, we must first delete the password on DEV (which breaks the applications on DEV. Then export the Database Thing for import to TEST. Once imported, the server team must then go in and re-enter the password on DEV, then TEST. Repeat for PROD. And if we have a simple error, rinse and repeat. It would be much better if you could decouple the CONFIGURATION (Userid/password, connection info, etc) from the database thing (or any other THING requiring a userid/password). The CONFIGURATIONS are named for easy referencing. This CONFIG block would be editable only by the server team, keeping it secure. This approach could eliminate the massive hassle that I just spoke of. This is how other platforms that I've worked with over the years handle this problem. The connection info is then kept secure while allowing us the ability to publish code agnostically.

olivierlp · ‎Jan 03, 2023

Hello,

We are archiving your idea as part of a general review. This action is based on the age of your idea and the total number of votes received, as per this announcement.

You can always post a new idea with all the details required in the form.

Thank you for your participation.