CIO-API: Configuration beeing used when updating rules

Question

Hi,
We're currently facing some issues when using the CIO-API to open an exisiting configuration, modify it and then save it again:
Since we had some minor issues in one of our configurator-extension-rules I changed that rule, updated it in configurator developer, tested it and published the new model to our testing environment. When opening "open" configurations from within order management, my new rules apply. However when using the CIO-API to access an exisiting model, the API still uses the old Model and the old extension-rules.
My API-Access is as follows:
CIO cio = new CIO();
ConfigParameters cp = new ConfigParameters(configHeaderId, configRevNumber);
Configuration config = cio.startConfiguration(cp, pCpContext);
//to some modifications
config.save();
cio.closeConfiguration(config);
When I modify this by adding "cp.setRestoreModelId( 281280);" before starting Configuration, my new model is used. However I don't understand why this is necessary and why this is contrary to what happens in order management.
Could someone clarify how exactly this is working? And: What happens when saving my model using the API? Does it always stay on the "old" level or does it get migrated when explicitly setting the latest restoremodelid on open or are there other circumstances when it's getting 'migrated'?
And is there an easy way to always use the latest modelId? For now I'd do the following select-statement:
select newpub.modelid from cz_model_publications oldpub, cz_model_publications newpub,cz_config_hdrs czh
where czh.config_hdr_id=123708240 and czh.config_rev_nbr=1
and oldpub.model_id=czh.component_id
and newpub.top_item_id=oldpub.top_item_id
and newpub.deleted_flag=0
But this seems a bit ugly?
We have no effective-dates or usages on our model if this is of any interest.
Regards,
Johannes

Answer 1

trol how it is restored/relaunched
1) config_model_lookup_date:-      Date to look up the publication for the configuration Model
For restored configuration: the saved value of effective_date(cz_config_hdrs), or SYSDATE, as determined by RestoredConfigDefaultModelLookupDate in CZ_DB_SETTINGS
Don't be surprised if you don't find RestoredConfigDefaultModelLookupDate in the table
2) config_effective_date:- The date used to filter effective nodes and rules
For restored(your case) effectie_date(cz_config_hdrs) that was saved is used as default. We can change this using settings
Now when we launch from OM the above are derived and sent as input parameters(based on your settings). If you want how your isntance is deriving let me know
For CIO unless you pass default are used.
Infact when in my code I used the below always to set it explicitly.
ConfigParameters cp = new ConfigParameters(latestModelId);
java.util.Calendar modelLookupDate = Calendar.getInstance();
cp.setModelLookupDate(modelLookupDate);
--you can add setEffectiveDate to be safe
Since you explicity set the restoremodelid that is taking care of it. But genereally the same can be achived by setting date parameters.          
If you have any questions around this area you can reach me directly.