There is a config in CustomerSettings.config
<add key="GSM.GlobalSuccession.MaxGlobalSuccessionSpes" value="500"/>
We don't recommend going beyond 500 and can't guarantee the system will perform. As with everything there is always an upper limit, so you may end up hitting it and having to do the replacement with db scripts. Can you run a query and see how many total specs are affected? For example, if its 550 you could push it, but if its in the 1000's you'll probably have to come up with a more technical hands on approach.
We are also running into this same issue. We have many raw material specs that are consumed in over 500 parent formulations. When a raw material changes, we have to have a way to get the new issue in the appropriate formula's without manual effort or going to IT run a db script. Is there a way for the global succession to at least return the first 500 formula's so that we can perform the replacement on those and then re-run it as many times as we need to to complete the updates?
also, is there a way to omit certain statuses from global succession. For example, we do not want or need to perfomr global succession on retired and/or obsolete formulations. This is a large majority of the parent specs, if we could take these out, our odds of exceeding 500 would be drastically reduced.
This really brings up a larger topic around change management.
The questions you should start with is
1. What kind of change is happening to the raw material?
2. Will this change affect anything upstream inside or outside of PLM4P? (Will this change affect nutrition, compliance, the ingredient statement, the label etc?)
3. Who needs to approve this change?
If they are non-material changes (changes that don't affect theoretical calculations, the ingredient statement, labeling, upstream systems that need to be notified etc) then you should be using get latest revision instead of global succession. Get Latest Revision will automatically switch out the material with the latest approved version. This logic is also configurable in case you need to add additional guard conditions. We can also provide guidance around locking the get latest revision lock once a specification has reached the retired/obsolete state so changes won't occur for specifications in those statuses.
If the changes to the raw material are material changes (changes that affect calculations, labeling etc) then the change should be reflected with a copy of the specification. Dependent specifications then need to be re-issued so calculations can be performed and the appropriate workflow reviews can occur. Smart Issue allows for filtering based on status and should let you re-issue in smaller blocks.
Let me know more about your change management strategy, how often large material changes happen and maybe example causes for those mass changes. We can also schedule a change management training session for everyone where we can share our vision and tools available for change management. This topic is quite large and generally requires a lot of business process discussion beyond just the tools available.
Would love it if we could set-up some time to discuss our change management strategy with you. Our business process does require smart issue for anyting that impacts roll-up calculations. We are only using global succesion for non-critical changes, which is the majority of our change requests that come in. I'll get with you to set-up a time to discuss. We have entertained the idea of get latest revision, but would like to understand more about it before we start using this as a solution for mass changes that impact more than 500 formulations.
Thanks Kelly.In the event log, I saw an error :ORA-01795: maximum number of expressions in a list is 1000 for your reference. As per my understanding the select query that is used to fetch the references is causing this issue as the "in" condition supports only 1000 PKIDs. for fetching the references and for some specs the references is >1000.
Kindly suggest what is a workaround for this.
What version of the application are you using? The error you are getting might be a bug.
Regardless, you should be able to do the following:
1. Increase the max result number for the global succession config. Depending on the number returned you will hit some sort of rendering limit, you can always increase the http time out to avoid not getting all results.
2. Run a succession in 500 spec count batches.
Global Succession uses stored procedures to retrieve the target specs and update the parent specs. You can take a look at those and use them if you want to orchestrate this manually. If you look at the Reg web.confg file you will see all of stored procedures used under the <SuccessionSpecType nodes.
We've run into the same issue as well in 188.8.131.52
I do not see a way to run in batches, but that would suffice in the short term. If greater than 500, you just get an error with no results. There isn't a way to filter the search, either, so its all or nothing. We increased our limit to 1000 and that is working for us without issue but running in batches or providing more filter critieria for a GS search would be a better solve. Thx
If 1000 is working for you then it sounds like you are good. But just in case it may help...
Global succession is a set of stored procedures in the database. So since we are using stored procedures for both the initial query and the execution of global succession you can adjust the initial query procedure to filter out specific statuses. This should greatly reduce your numbers . For example, you can set the system up to not return any specifications in an archived or inactive state.
Here's a thread that talks about those stored procedures:
We do hope to offer a status filter in a future release for smart issue and global succession. But please submit any enhancement requests detailing your business problem so we can make sure the kinds of filters you need are available.