Loading in an RMB File

  • loffo

    loffo - 2004-09-14

    Hi There

    I have been asked to try and write a routine to take the RMB file from Niku and save it an a format that another package accepts.

    To do this, I basically need to just load the RMB file and iterate the Object Model and create my own outputs.

    I have started with the com.abtcorp.io.client.pmwfile.FileAnalyzer which I have compiled successfully and into this I have changed the RMB file referenced. I tried to run that and ended up getting a message about currencies. I then added the following to the hash table:
                    new ABTString( KEY_IGNORE_BASECURRENCY ),
                    new ABTBoolean( true) );

    This got past the currency issue but now I get stuck on an error:
    ABTError:com.abtcorp.io.client.sitefile.ABTIOSiteFileDriver, populate, An Error Ocurred :com.abtcorp.core.ABTException: Object type: processSite, Exception name: , Error text: Site data is not found.

    I traced this thru for a very long time and was not able to go past this.

    I tried with different files, in case it was related to my file but this did not get me anywhere.

    Is somebody able to point me in the right direction with what I am trying to do? Is perhaps using FileAnalyzer not a good starting point?

    If anybody else has done something similar, sample code would be appreciated.

    Thank you


    • Dan Dumbrill

      Dan Dumbrill - 2004-09-14

      I'm assuming that you are referring to RMP files not RMB's.  Is that correct? 

      The preferred method would be to use the XML format that Open Workbench can save.  This is the format designed to be the "Open" approach for reading and writing Open Workbench Data.  

      Another, much less desirable but more appropriate, method of creating a new file format is to create a new driver so users can choose, from the UI, which format they'd like to read or write (XML, RMP or your new format).  This is the right approach, especially if the product you are interfacing with is of interest to other community members. 

      The new driver approach is more difficult than using XML since both C++ and Java code must be written.  In the future, it would be nice if persistence drivers were pluggable from the C++ perspective so theyd be automatically recognized and used without C++ code changes.

      Any other approach feels, to me, like a Band-Aid type change that might get you in trouble with subsequent releases of Open Workbench.

    • loffo

      loffo - 2004-09-14

      Thanks for your reply.

      Yes, sorry, I had RMB on my mind when of course I am meaning RMP.

      Let me clarify further what I am doing. I am not in any way changing the OWB client, instead I am using the OWB source supplied to create a standalone java program to try and read the RMP file format and then import this into the application I am managing. Users will continue to work with RMP files thru OWB (or Niku) and they have no need to export or save as XML. There will be a directory of RMP files that I will upload to my application on a daily basis. So, basically I want to try and extract out some of the info from the RMP file by using this source code.

      I also plan a little 'dump' type utility which can dump the contents of the RMP file passed in the command line to standard out. This I will contribute back to the open source project, if they want it.

      Assuming I always use the current source then I am sure that there would be no troubles reading the file formats.

      Now back to the original problem - any suggestions on a way forward?



    • loffo

      loffo - 2004-09-20

      Well, I have now progressed what I am doing and would like to point out a few little things to those who venture into thw java code.

      1) If using FileAnalyzer.java to try and read a file, you must set either the
      os.setRuleFileLocation method or os.setRuleBaseZipFileName

      if you don't, you get the cryptic errors that I refer to above.

      2) if you plan to save your RMP file to XML, you must use os.setRuleBaseZipFileName as the XML routines crash if you use os.setRuleFileLocation

      3) If you want to try and understand Niku's internal Object structure, don't - it's very complicated. My suggestion is to take the RMP file and save it as XML (either from the OWB, or via this code below) and then use the XML and parse that.

      For those that are interested, here is a code nippet that loads up the RMP file and saves it as XML:

      // setup parameters
      String sRulebaseFile = "c:/temp/RuleBase.jar";
      String sOutputFule = "c:/temp/niku.xml";
      String sInputFile  = "c:/temp/niku.rmp";

      // init niku
      IABTValue project;
      IABTObjectSpace os = new ABTObjectSpaceLocal();
          ABTIOPMWFileDriver driver = new ABTIOPMWFileDriver();
          IABTHashTable ht = os.newABTHashTable();

          // setup a hash table for niku wit hall the parameters
          ht.putItemByKey(new ABTString(IABTDriverConstants.
              KEY_SOURCENAME), new ABTString(sInputFile));
          ht.putItemByKey(new ABTString(IABTDriverConstants.
                  new ABTString(IABTDriverConstants.TYPE_PROJECT));
          ht.putItemByKey(new ABTString(IABTDriverConstants.
              KEY_IGNORE_BASECURRENCY), new ABTBoolean(true));

          project = driver.open(os, ht);
          project = driver.populate(os, ht);
          if (ABTError.isError(project))
              return "Error loading Niku Project";

          // now, save the project loaded as a niku formatted xml
          ht.putItemByKey(new ABTString(IABTDriverConstants.
              KEY_DESTINATIONNAME), new ABTString(sOutputFile));

          ht.putItemByKey(new ABTString(IABTDriverConstants.
              KEY_SOURCE), project);

          XMLFileDriver xmlfd = new XMLFileDriver();
          xmlfd.save(os, ht);
          xmlfd.close(os, ht);
      catch (Exception e)
          return "Niku Error: " + e.toString();
          // end the niku session.

      return "Loaded File OK";




Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks