Aurena Context

You should be able to export the configurations as ACPs, which will at least retain what you’ve done.  You can see some steps for best practice here:

However, to reset the Global context, you will likely have to recreate the environment (hopefully you aren’t live already) so you have a clean installation.  Then create a new context, we created one named with the company name and Global to differentiate, i.e. “Company Global”.

The tricky part will then be importing the saved ACPs but directing them to the new context rather than the one they are saved in from the previous environment.  That part I’m not sure how to make work as I haven’t done it.  You should be able to try that out within the same environment, export, create the new context, then import to the new context to make sure it will all work.

You definitely don’t want to modify the Global context as it makes dealing with future releases very problematic as they won’t get recognized if the Global context has been modified without unpublishing the configurations then publishing them again after the changes are picked up.

@ShawnBerk - If you don’t modify the Global context, do you have any suggestions on how to make changes that everyone should see but also have custom context for certain screens? We have scenarios where certain groups need to see specific screens differently than everyone else. 

@SaraCrank 

You can make a new company centric Global context that contains everything that you need everyone to see, then make a third one that is customized to a particular group of users as needed.  It is at least flexible in that regard.  Just remember that for every additional context you have, when you get updates and service releases, those contexts will have to be unpublished and republished to pick up the changes that you will be able to see in the Global context.  With the flexibility comes an enormous growing maintenance debt to maintain the software.

This is when you come to the realization that the evergreen model simply means pushing down all of the maintenance and headache to maintain to the customer.  If you forget or mess it up or don’t have a tightly controlled mastering schema, you end up either losing the configuration changes you’ve added when you apply an update or you don’t get the enhancements added by IFS because they don’t get applied to custom contexts without manual work.

We are keeping the IFS Global context untouched, then all new changes in releases can be seen directly in the IFS Global context, but we don’t want any users to see or use the IFS Global context.

We are trying to force all users to use the Instron Global context which is the company global view for 95% of the configuration changes.

On the handful of pages so far where we want one version for everyone (view and analysis type users mainly) and a different context for data entry, then we create a third that is given to a limited set of users.  We keep track of these exceptions so we only have a small number to manage and we really analyze whether this difference is needed before enacting it.

For the ACP packaging, you can do it by page, but that becomes too granular.  We think from experience that doing it by large process areas or functions is best and rolling up all of those things in one ACP becomes a bit easier to manage as there aren’t as many of them to keep track of.  It somewhat matters how many different analysts/developers are making changes and whether you are storing the master in the Build Place or in an outside of IFS repository.  You want to be able to really keep track of the revisions (small control group), but you don’t want to so lock it down that multiple analysts or groups can’t work in the same area.

We are trying to require some documentation in our change management system as well so there is a change record as to how, when, why, and who created the change and to which environments it has been checked or deployed, but that is still and evolutionary process.

I don’t know there is one correct answer for every installation, but that is the most general guidance I can offer.

@ShawnBerk - Thanks for the info! You mention multiple developers, have you had any experience with multiple people working on the same projection at the same time or do you break your work down by page?

I am thinking of what are the benefits of keeping the global context intact?

• After IFS update/delivery, clearly reflect the new update to the user from global context if it is intact
  • can we achieve same by taking ACP backup and unpublishing the global context changes and reimporting ACP from the backup?
  • or just unpublish and republish works will result the same? 
• any other benefits?

• can we achieve same by taking ACP backup and unpublishing the global context changes and reimporting ACP from the backup?

IFS is not going to tell you where they’ve made changes or what the change might affect, so unless you have a plan to go and unpublish and republish every configuration change in every ACP for every update even a service update, you won’t know what changed.  We’ve not found any better way to do this than as I’ve explained.  I’ve heard from other customers who were deploying Aurena early on in V10 with a similar experience.

-Of topic

Not an answer to the original question. I just post this because a big portion of this thread have been about global or not. So I just add a small note around this. If there are further inquiries about that. I suggest you start a new separate thread for that. 

@ShawnBerk - With the rebase tool introduced in 23R1, you will now see what changes IFS have made. Well not every change but the changes that IFS made in the client for the same artifacts that you have configured. This also means that you get to “merge” your configurations with the delivered changes.