Versioning of Trigger Scripts and Report Recipes in Integrity Lifecycle Manager

[chirag_kpit]

How can we enable versioning of Trigger Scripts and Report Recipes in Integrity Lifecycle Manager?

Better  if this can be done using some solution related to configuration Management.

[kjain-2]

Hi Chirag,

Do you mean to store the trigger scripts & report recipe files in any version control tool?

If this understanding of mine is correct, then you may use SVN / GIT / IBM Clearcase / Integrity SCCM or any equivalent tool depending on your company's standard policy.

Grube,

Kapil

[chirag_kpit]

Hi Kapil,

I am looking for a solution using Integrity SCCM, but how can I implement it.

Regards,

Chirag Agarwal

[kjain-2]

Hi Chirag,

May i know what is the exact scenario for which you are looking into this requirement ?

Grube,

Kapil

[chirag_kpit]

Hi Kapil,

I don't want to give server access to any user and also i don't want users to make changes to any directory using URL.

I want users to checkout the trigger script and check in, for changes to reflect in the server directory , this is how i am looking to implement it.

Regards,

Chirag Agarwal 

[MichaelChatel]

At least in the case of trigger scripts, are these users making changes to admin objects, not supposed to have admin access to the server?  It's not like any old user will have access to edit trigger scripts?

This seems like it could get messy, and that you would have to do a bunch of copying of "checked-in" scripts, to the proper locations, to use on the Integrity server.  I don't know anyone doing this.

[chirag_kpit]

Hi Michel,

May be it seems messy but it's not. Some customers have such functionality and some customers are willing to have such feature. I am actually using this but not knowing how this is implemented.

This will help users and implementors in various ways-

Let's say you are not willing to give server access to all the users then this will be helpful by giving project permission to specific set of users, another if you want to revert the changes in script you can directly revert if have such functionality and also you can compare the difference in two versions and many more.

This feature very powerful.

Regards,

Chirag Agarwal

[mks2019]

Will it be possible with File Vaulting?

just a guess.

[JoeBartlett]

Anecdotally, I have seen one customer with this kind of configuration. If I remember correctly, they had created a group for Admins and created a new top level project for the server trigger files. /ServerConfig/project.pj or something similar, which only the Admins group had access to.

They had used an Integrity Client installed on the Integrity Server machine and they created a sandbox in the same location as the <IntegrityServer>/data/  folder such that all of the files and folders within that location were considered Members of that ServerConfig project.

Since they had locked-down the permissions to only the Admins group, normal users could not access that project or make changes to the files - only the Admins could. They would only make changes to the files by using the client on the server, and this would be tracked by Integrity as new versions of the files.

The risk to handling the server config files in this manner is that if an admin were to accidentally drop the sandbox on the server and choose to "delete everything" when prompted, the server would not be able to start next time the service is cycled. With the server not being able to start, it would be impossible to retrieve any earlier versions of the files from Integrity since it would be offline. An apt analogy for this would be locking your car keys inside your car. If you plan to go with this configuration, know that it is not recommended by PTC and you are very strongly encouraged to take filesystem-level backups to mitigate that risk.

[VolkerEckardt]

In my current project we handle this the following way:

1. we have an additional project Integrity Server

       Key Users, PMs, Developers will usually have access to

2. in this we handle everything like 

       a) project documentation

       b) custom user manuals

       c) configuration tests and test results

       d) source code including Java, Trigger, Reports, Templates, ...  just everything

       e) Change Requests and Defects

       f) Business User Stories to link code, CRs and Defects to.

3. When a developer is ready with his own development, we check the result in into the project server, and perform a formal validation.

When ok, we deploy the solution selectively into the TEST > QA > PROD chain.

4. The configuration manager is responsible to take the changes up and promote them as requested.

We are also using some helper scripts to make sure that everything is stageable, e.g. also Gateway files. 

[chirag_kpit]

Hi Volker,

Thanks for your response.

Your understanding is exactly same that i was looking for.

So, I would like to know how this solution has been implemented because configuration manager checks-in the file into  the database not in any physical location/directory.

Regards,

Chirag Agarwal

[chirag_kpit]

Hi Joe,

Thanks for your response.

In Case, we installed Integrity Client on server and  created a sandbox  with Integrity Server directory Locations then how, the checked in files are getting reflected into the server directory without re-synchronizing the sandbox ?

As per my knowledge, files will not be physically available without re-synchronizing the sandbox.

If you have created any trigger or script for this then how you manage to create the event?

Regards,

Chirag Agarwal  

[AP_11714902]

I am exactly facing the same issue? Do you got the solution?

[LLawton]

I think this is a very long thread to not answer the question! 😊

This is my answer to "How can we enable versioning of Trigger Scripts and Report Recipes in Integrity Lifecycle Manager? Better  if this can be done using some solution related to configuration Management."

1) Create a CM project on whichever Windchill/Integrity server you want (in my case PROD). Obviously, you can set the appropriate permissions so only authorized users can view/use the project.

2) Create a sandbox with any client on any computer. I recommend to NOT do that on the server and certainly NOT create a sandbox in the server installation folder(s).

3) Copy the files you want to put under CM from server to sandbox, and add them to the project. Now your files are under CM, and moving forward, you use check-out/in and add as for any development project.

In my case, I have a DEV server staged to a PROD server. I have the DEV files under CM, but stored on the PROD server. Nothing wrong with that, it's the PROD database that's the official one.

When I have an important update, I do a check-out, then use Beyond Compare to sync my sandbox to the DEV config,, then check-in. It's manual but controlled and safe.

You could automate things a little more with a trigger script called "mirror.js" that allows to replicate files from a project to a directory location on the server. In this case, changing a file in the sandbox and checking it in would trigger a copy of the latest revision on the server's config location.

However, in the case of trigger scripts and report recipes, I recommend to NOT do that. That's because you cannot develop them efficiently in a separate environment, you have to do that on your server (DEV in my case) so you can test them. So in my case, whatever file I would check-in is already on DEV, and therefore there's nothing to mirror. If somehow you can develop your scripts/recipes outside of DEV, then using mirror is a solution but personally I don't see how this works or is efficient..

In any case, do NOT create sandboxes in your server installation folders, that is a recipe for trouble. Same goes for file vaulting in your server's installation folder, that's another invitation to disaster.