4 Replies Latest reply: Mar 30, 2012 6:01 AM by Johannes M RSS

    CIO-API: Configuration beeing used when updating rules

    Johannes M

      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

      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.


        • 1. Re: CIO-API: Configuration beeing used when updating rules
          Johannes M
          Just in case anyone is interested: This is what we programmed to always open the latest model:

          private PreparedStatement newestModelFinder=null;
          protected ConfigParameters getConfigParameters( long configHeaderId, long configRevNumber,
          boolean openWithLatestRules) throws SQLException {
          ConfigParameters cp = new ConfigParameters( configHeaderId, configRevNumber);
          if ( openWithLatestRules) {
          if ( newestModelFinder == null)
          newestModelFinder = mCtx.getJDBCConnection().prepareStatement(
          "select newpub.model_id from cz_model_publications oldpub, cz_model_publications newpub,cz_config_hdrs czh where czh.config_hdr_id=? and czh.config_rev_nbr=? "
          + "and oldpub.model_id=czh.component_id and newpub.top_item_id=oldpub.top_item_id and newpub.deleted_flag=0");
          newestModelFinder.setLong(1, configHeaderId);
          newestModelFinder.setLong(2, configRevNumber);
          ResultSet rs = newestModelFinder.executeQuery();

          if (rs.next()) {
          int newModelId = rs.getInt( 1);
          cp.setRestoreModelId( newModelId);
          } else {
          return null;

          return cp;

          Any hints if there is some more simple or elegant solution for this?

          • 2. Re: CIO-API: Configuration beeing used when updating rules
            murali koganti231503
            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();
            --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.
            • 3. Re: CIO-API: Configuration beeing used when updating rules
              murali koganti231503
              Sorry some of my text was cut from the posting...

              -Murali Koganti
              • 4. Re: CIO-API: Configuration beeing used when updating rules
                Johannes M

                thanks for your reply. setting the modelLookupDate was my first try. This didn't and doesn't (just retried it) work for me. It stays using the old rules (especially for java-rules). So I'll stick with my little select for now, this at least works :-)