Change (or in this case, updates) can be so, so good!
Beginning with v3.0 of RPG-XML Suite, Krengeltech has introduced a new and improved method of composing XML via a template. We like to call this new method “compiled templates” and it has some great advantages:
- Accessing the IFS at run time is eliminated and performance is improved as a result.
- The CRTRPGTPL command provides actual RPG variable names for your program to reference, eliminating the use of literals.
- RPG programs are now more portable across partitions and machines without concerns about template data being in-sync
In previous versions, template files were always located in the IFS and accessed as your program was executed. While this worked OK, the reliance on the IFS meant that performance was somewhat reduced because of the need to retrieve the template from disk.
With “compiled templates” the template file located in the IFS is now converted into RPG source code using the command CRTRPGTPL. There is no longer any need to reference a template file at run time, since the template’s contents have already compiled into the program object. Once the CRTRPGTPL command is executed, you copy it’s output into your RPG programs using /COPY in D-Spec’s and again at the bottom of your program. Then you simply load the template into memory by specifying the name of your template sub-proc, like so:
ComposeDS.TemplateProcedure = %Paddr(Template);
(See this page for a complete RPG code example.)
Because the CRTRPGTPL command outputs code for actual RPG variables representing the template section names and template variable names, you no longer need to use literals in your API calls. Literals are subject to coding mistakes that the compiler will not be able to catch, whereas the using the RPG names produced by the CRTRPGTPL command will cause a compiler error that you can reference, should a mistake be made. Since you can refer to the compiler listing to locate and correct errors you have made when referencing your template section/variable names, you don’t have to waste time and effort tracking down simple errors at run time the way you had to when using literals.
By not creating an IFS dependency at run time, you are free to move the program object to other machines or partitions, without being required to also move the latest changes to your template file. In fact, you don’t need the IFS version of the template to exist on any machine/partition other than the one where you do your development. For those with source code management systems, this means you can also include RXS templates for tracking and deployment.
Hopefully you find these improvements to template processing helpful in building quality web services to meet your business requirements! Contact our development team at email@example.com with any questions you may have as you put compiled templates to work in your organization.