Fearless ns and nsmulti

Writing ns and nsmulti operations in Curam requires a build generate in order for you to even test them. These operations tend give the aggravation when you do it incorrectly, since there is little build time checks and can only be tested on runtime or unit tests. Well I don't like suffering too much either, so when I write my ns and nsmulti I usually write a test case to go with it. Nothing complex, it just looks like this.

public void testNsMulti throws Exception {
 Configuration.setProperty("curam.trace.sql", "true");
 Entity.nsmultiop(new Key());
}

public void testNsthrows Exception {
 Configuration.setProperty("curam.trace.sql", "true");
 try {
   Entity.nsop(new Key());
 } catch (RecordNotFoundException e) {
   // do nothing, needed because ns
   // does not provide a
   // NotFoundIndicator version.
 }
}

The configuration line ensures that the SQL gets outputted to standard output. Helps when you are debugging your SQL. I usually just do it in the test rather than in the setup because I normally would want to remove it after the test is complete. These would most likely yield no results, which is fine when you are starting. The idea is to ensure that the generated SQL does get processed successfully by the database in the end. If you're a perfect SQL writer, then no big, everything works fine. However, if you are like me when you are dealing with a large number of tables, some times things get missed. In which case you'd get a stack trace coming up. What you want to look for in the stack trace is the name of the base class for the entity. Sure you can type it in, but its just as easy to double click on it. What you are looking for is the SQL string which looks something like private static final String nsmultiop$SQLString = "..." or private static final String[] nsop$SQLStringArray = { "oracleSQL", "db2SQL", "db2ZosSQL" } That string can be changed as you see fit until your test cases pass. Just a caveat build generate will remove any changes you made to the base class. So make sure you save what you did. What I do is modify the operation to have something like: System.err.println(nsmultiop$SQLString); or System.err.println(nsop$SQLStringArray[1]); // since I use DB2 This prints out the SQL string and I can paste it onto my trusty SQL formatter then paste the the formatted results back into Merlin toolbar. If you want to avoid Merlin like I do, you can double click on the operation and in the comments area for SQL="", just paste in the SQL.