Contents
Contents
Property |
Detail |
Purpose |
Displays the current configuration. |
Description |
Displays a set of environment variables and settings that may be needed to diagnose compile issues. |
Usage |
displayEnvironment.bat |
Parameters |
None. |
Property |
Detail |
Purpose |
Sets the current development environment (project) for the software development kit. |
Description |
Displays a list of development environments on the development client, allows the user to select one, and sets it as the current development environment for the software development kit. |
Usage |
switchEnvironments.bat |
Parameters |
None. |
Property |
Detail |
Purpose |
Creates a new development environment (project) or configures a development environment to use the version of the software development kit used for the current development environment. |
Description |
Configures a new app server to be a development environment. Also, executing this for an existing development environment configures that development environment to use the version of the software development kit used by the current development environment. |
Usage |
createNewEnv.bat -a <appServerDir> |
Parameters |
· -a <appServerDir>. Specify the base directory of the app server to configure. |
Contents
Batch Program setupSvcXMLPrompted.bat
Batch Program updateXMLMetaInfo.bat
Property |
Detail |
Purpose |
Setup service XML. |
Description |
After prompting the user for the program name of the service, this script sets up a service by creating the service XML file. |
Usage |
setupSvcXmlPrompted.bat |
Parameters |
None. |
Property |
Detail |
Purpose |
Updates the XML Metainfo directory with the latest service XMLs. |
Description |
Updates the XML Metainfo directory of the current development environment with the latest service XMLs. This is needed, for example, for creating schemas for XAI. |
Usage |
updateXMLMetainfo.bat |
Parameters |
None. |
There are a few wizards and tools available for developing against the framework within Eclipse plugins.
Contents
Batch Program startEclipse.cmd
Property |
Detail |
Purpose |
Launch the Ecliipse SDK for the current development environment (project). |
Description |
Launches the Eclipse SDK for the current development environment. |
Usage |
startEclipse.cmd. |
Parameters |
None. |
A lot of the Java classes that will be created to add behavior to the application require Annotations to provide meta-data about the implementation (see Java Annotations chapter in the Developer Guides).
The annotation editor plugin provides a convenient way to edit the annotations on these classes. It is available on any class that has an existing annotation, under the package explorer panel in eclipse. Right click on the file in the package explorer, and there will be a menu item “Edit Annotation”.
Choosing this menu item will cause a new dialog window to appear, and the file to open into an editor if it is not already open. The dialog that appears will allow maintenance of the file’s current annotation contents.
The appearance of the dialog is dependent upon the particular annotation, but the standard dialog will present a layout of two columns, a label and an input for each annotation property. The bottom of the dialog will always present the Finish and Cancel buttons. The Cancel button is always available, and will throw away any changes made, leaving the file with the annotation unchanged.
The Finish button will only be enabled when the annotation has no errors. The annotation is validated after any change, and errors will be displayed near the top of the dialog and the Finish button disabled.
When the property value is itself a list of values or another annotation, there will a button instead of an input text box. Clicking the button will bring up another dialog to edit its information. In the case of lists, there is a standard dialog where elements can be added, deleted, or reordered.
To add a new element, click the ‘+’ button. This will popup a new dialog for the annotation being added (or sometimes a choice of the new annotation’s type might need to be chosen first). Clicking the ‘-‘ button will delete the highlighted element. The ‘up’ and ‘down’ buttons can be used to move the highlighted element up or down within the list. To modify an existing element, double click its row in the list dialog, and a new dialog will open to edit its values.
Finally, there is a special list dialog for lists of strings. Instead of editing the elements in the list in a new dialog, a single input field near the bottom of the dialog is used to edit the highlighted entry.
When the finish button is finally pressed, the annotation (and only the annotation) in the file will change to contain the new values entered into the annotation dialogs. The changed file’s annotation may be slightly reformatted. The changed file will also remain unsaved, pending user review of the annotation’s changes.
In order to use the Maintenance Object Wizard described in the next section, some information will have to be provided in order for eclipse to connect to the database to retrieve the Maintenance Object meta data.
There are two ways to specify the database connection information.
The first is a way for each project to possibly specify different connection information. This is done in the .project stored in the project’s directory. This is an xml file that describes the project. The database information can be supplied in a buildCommand node under buildSpec under the projectDescription root node:
<buildSpec>
<buildCommand>
<name>com.splwg.tools.dbConnection</name>
<arguments>
<dictionary>
<key>url</key>
<value><URL></value>
</dictionary>
<dictionary>
<key>username</key>
<value><USERNAME></value>
</dictionary>
<dictionary>
<key>password</key>
<value><PASSWORD></value>
</dictionary>
</arguments>
</buildCommand>
…
</buildSpec>
The values <URL>, <USERNAME>, <PASSWORD> should be replaced (including the surrounding ‘<’ and ‘>’) with the appropriate values for the database for the project.
This file will need to be hand edited, and eclipse should be restarted after the edit is complete.
The second way is to provide a workspace-wide database connection. This is available in an eclipse preference- go to “Window | Preferences…”. Then in the tree pane on the left of the Preferences dialog, choose “SPL Preferences”. Under SPL preferences, choose “Database Connection”. The preference pane on the right will now show inputs for the database connection information.
Click the override default DB connection if the database contains materialized views to the true development database for performance reasons. Enter the information into the appropriate text boxes and click OK. This will take effect immediately, without need of restarting eclipse.
In cases where a whole new “Maintenance object” is being added to the application, and the data is first entered onto the CI_MD_MO and related tables, there is a wizard that will use that meta data as a starting point and with some developer input, create all of the manually coded Java Entity_Impl classes with their proper tree structure, and also optionally create a Java Maintenance class “starting point”.
The “Maintenance Object Wizard” is available under the “New ..” menu item, either under the file menu, or by right clicking a node in the package explorer (the package explorer option is recommended, as it will default the project and source directory selected). From the list of new wizards available, choose “Other…”.
This will open a new dialog, where the maintenance object wizard is under SPL:
(Note that you can configure eclipse so that in the future the “Maintenance Object implementation classes” wizard appears directly under the first “New…” menu.)
The first page of the wizard asks for the project and source path to place the new files. Then it asks for the some information it uses to construct the package name for the new files. The standard is that the new classes go under the application’s domain path, with a possible extra sub package (e.g., a subsystem, like ‘common’ or ‘customerInformation’), followed by the top level entity’s name (e.g., account). The top level entity’s name, along with lots of data used by the next page, comes from the maintenance object itself.
Finally, you can optionally choose to Generate the UI Maintenance (the default is to generate it).
The maintenance object input has a “Browse…” button associated with it that will launch a search dialog where the maintenance object can be searched for by either the Maintenance Object’s code, or by the primary table for the maintenance object.
Both of these searches are “likable” in that partial matches starting with the input will be shown.
Pressing OK on the search or double clicking a row will bring the selected maintenance object back into the Maintenance Object input on the main wizard.
Once the main wizard’s inputs are specified, the next button can be pressed. This will display the second detailed wizard page. A tree view is displayed with the tree representation of the Maintenance object selected, with its child tables.
Each node in the tree must be visited in order to enter some information or at least verify that the default data is correct. The nodes themselves show the list property name, the table, whether the table has a language table, and whether the node has been verified.
The selected node’s data is shown in the “Info” box below the tree. Only editable information is available to be changed- other values may be disabled. The values that can be changed for each node include the list property name, the order by fields, the clustering parent property, and whether the Id can contain mixed case.
The list property name is the name on the parent that the child collection will be accessed by. For example, in the above Maintenance Object for Table, the table’s child collection of rows on the table CI_MD_CONST will be accessed via the property ‘constraints’. And likewise, each constraint will then have a child collection called fields.
The order by is an optional property. It is a comma-separated list of columns that specify the order in which the list will be retrieved when the collection is read from the database. An example for the constraints collection would be “CONST_ID, OWNER_FLG”.
The clustering parent property comes into play for generated IDs. In some cases, it is beneficial to cluster the generated keys for related objects so that batch threading is more efficient. An example is every Service Agreement can have its ID generated with some portion of its account ID. The account will be accessed off of a serviceAgreement via the property account. Thus the Service Agreement root node in the above dialog would probably have a value of ‘account’ for the clustering parent property.
In case of user defined string keys, most of the time the application only uses uppercase keys. However, in some cases, mixed case keys are allowed. The “Allow mixed case Id” check box should be checked in this event.
Finally, to ensure that the developer reviews each node’s values, the Verified check box must be checked for each node, prior to proceeding to the next page or finishing.
If the option to generate the Maintenance was not chosen, the Finish button will be enabled when the tree nodes’ data is complete and valid. Clicking finish will cause all of the entity classes to be created in the specified package, and will open an editor window on each new class.
If the option to generate the Maintenance was chosen on the first page, the “Next>” button should be enabled after all the tree nodes data is finished and valid. Clicking “Next” will then present the final wizard page, where information about the maintenance class can be entered.
On this page, the maintenance class name and maintenance type can be chosen. The maintenance class name is something like the root entity name followed by ‘Maintenance” by convention, although it can differ. The maintenance type choices are ‘Entity’, which is a standard maintenance for a single instance of the maintenance object at a time, with nested child lists, etc. The other choice is ‘List”, which is a simplified maintenance where many instances of the maintenance object are edited at once in a grid. This is usually limited to simple objects with a code and description, and maybe one or two other fields. Anything more complex would be difficult to present in the single grid.
(Note that changing the Maintenance Type will clear out any existing information on the annotation.)
After the class name and maintenance type is chosen, there is more information required to be edited on the Annotation. See Java Annotation in the Developer Guide for details about annotations. Clicking on the “Edit Annotation” button will launch a new dialog window for editing the annotation. The most important information that every maintenance must specify on the annotation is the service name. This field is immediately visible on the main dialog for the annotation, and must have a value entered. Most everything else will have been defaulted with appropriate values from the Maintenance Object meta data. See the developer guide mentioned above for more information on using the annotation editor.
After the maintenance information and annotation is complete and valid, pressing finish will cause the entity files and an empty maintenance class to be created, and editor windows opened on each of them.
Note. JSPs other than trees and subpanels must have been upgraded to XSLTs in v1.5.x. Thus, there is no tool to upgrade such code in V2.
Contents
Batch Program convertTreePageExits.pl
Batch Program convertSubPanelExits.pl
SQL Script changeTemplateCodesTTRAndPN.pl
convertTreePageExits Description
Creates user exit files from tree JSP files.
This program creates user exit .xjs files for all tree JSP files under the current and child directories. The .xjs file will be created in the same directory with the same name as the JSP.
This should be run from a command prompt in the directory or parent directory of the JSP files.
Perl convertTreePageExits.pl
Contents
convertSubPanelExits Description
Creates user exit files from subpanel JSP files.
This program creates .xjs files for all subpanel JSP files under the current and child directories. The .xjs file will be created in the same directory with the same name as the JSP.
This should be run from a command prompt in the directory or parent directory of the JSP files.
Perl convertSubPanelExits.pl
Contents
changeTemplateCodesTTRAndPN Purpose
changeTemplateCodesTTRAndPN Description
Changes the tree and subpanel template codes to the XSLT template codes.
This changes the template codes of from JSP to XSLT template codes. This template code instructs the application to use the XSLT engine instead of the referring to a JSP.
These SQL commands should be run against the database.
Contents
Batch Program generateJavadoc.bat
Batch Program reindexJavadoc.bat
Property |
Detail |
Purpose |
Create javadocs from custom source code. |
Description |
This script runs the javadoc tool bundled with the jdk against CM source code in the standard directory and targets the javadocs directory in the Application Viewer. To integrate the javadocs with the product’s javadocs the reindex tool needs to be run. |
Usage |
generateJavadoc.bat |
Parameters |
None. |
Property |
Detail |
Purpose |
Recreate the Javadoc indices. |
Description |
This script recreates the Javadoc indices so that it shows all of the Javadocs in the Javadoc folder. If Javadocs have been generated for CM code, this will update the indices to include both the CM and the product’s classes and packages. |
Usage |
reindexJavadoc.bat |
Parameters |
None. |