Timers/schedulers and user context

[ZbigniewK]

When creating a scheduler or timer, I do create a dedicated user for it. And it's local TWX user, no some Active Directory user, etc.

This user is given permissions for all Things/services which are required when scheduler/timer is triggered. 
Everything works perfectly at development server.

Unfortunatelly, during deployment, this user is not deployed to production server. Because user are never deployed. And I have no admin rights at production to create this user, and set permissions again.

I could set administrator as user context for timers/schedulers, because such user already exists at every server... but as far as I know it is recommended not to do so, for security reasons.

Is there any other solution to cope with that? 

[Velkumar]

Hi @ZbigniewK 

You can include user in your project and export / import in different environment along with Timer/Scheduler.

As a post deployment activity, you can create a service which will provide runtime permission to User for Timer / Scheduler.

This way you can avoid creating user manually in Production environment

/VR

[ZbigniewK]

1. Yes, adding user to project was so obvious for me, that I even did not mention. I treat user as one of resources, all resources are assigned to project. 
2. As a developer, idea is I will be NOT allowed to import anything. And user will be not transfered during development. That's what my DevOp says. Because PTC does not recommend to deploy users. 
3.  Probably I could also create user via service. But... this service will need to have permissions, probably higher than my on Prod server, am I right?  So, will it work? 
Also,  if I have to set anything on Dev server graphical way, test it, then create service to do exactly this same but by code... so where's profit of using graphical, low-code enviroment as TWX?  

[VladimirRosu · Accepted solution]

Ref 2: If that statement is correct (I'm not sure where it's mentioned), then you should note that it's a recommendation, not a mandatory step. This means that in cases you find it valid, you can choose not to obey that recommendation. If it would have been mandatory then we would not have the capability to import Users.

Ref 3: that service will be executed by the Administrator. I find it hard to believe that the deployment itself is executed purely by an user that's not Administrator, right?

The idea is that the deployment process should not consist only in deploying (via Import/Export files or extension), but should include a "Post" install step, that will be execute by the actor doing the deployment (which can be either a human or an orchestrator like Azure DevOps workflows).

This "Post" install step should include all plumbing things like the one we discussed here.

Ref the last statement: the right way to look at this is the fact that you have APIs available for you to solve almost any possible situation that could arrive in production. The power of those APIs you use in your services is that they give you the power to build any sort of workflow you might think of. That same flexibility is almost impossible to re-create in a single UI (Composer) for all use-cases.

[ZbigniewK]

3. DevOp will deploy whatever he/she finds is important, nothing more.
On dev server, I can prepare Thing service to create user and set permissions, and also mashup with button to start it.
It will be deployed to Prod server. So I can call this mashup, push button... it will start service with my access rights. If I have no access rights to add user via Composer, do you think this button will create users?

Btw, (if I convince my DevOp) is that TECHNICALLY possible to deploy user during deployment? If user would be deployed before other entities, then all entities could be deployed with permissions including this user already?
From developer point of view, it sounds like easiest - copy working project with all required resources/entities, what can go wrong?  

[Velkumar]

Hi @ZbigniewK 

As @VladimirRosu suggested there should be some post deployment activities need to be carried out in your case.

You don't need a Mashup to create a new user / user group. You can bundle existing User ( not all users only system account or service account which runs timers / schedulers ) / User Group and create a service in development instance which will assign permission to required entities post deployment.

You can execute permission service in multiple way :

1. In DevOps Pipeline, after the automated deployment / import stage completed. DevOps Pipeline can call / execute permission service in Thingworx to assign required permission 

2. Or once the DevOps deployment is completed. You can ask IT Team ( who manages Production Server  / Administrator of Production server ) to execute that service manually to assign required permission in Prod. 

You can make post deployment activity as mandatory step in App deployment process.

/VR

[ZbigniewK]

"You can ask IT Team"
No, I can't. There is no such person. It's like sending to dev/null.

More you (both) say, more I'm sure, our deployment process is wrong. That was difficult problem for me, because personally I have no comparison from other companies how deployments usually work, and in my (corporation, or just in this team) deployment process is still not fully developed. It's more developer AGAINST DevOps battles. 
Hope, if I present your arguments, there will be more understanding for requested issues, and it will be not treated as one-person ridiculous claims.