The first step in creating a Configuration, Fault or Performance Management Application is creating a Project. The Project holds all the applications for building the Application. An overview of the stages in creating a Project and getting started with the management Application building process is discussed in brief in this section.
Creating a New Project
To create a Project click on File-> New from the menubar or click the New icon in the toolbar. In the dialog that appears enter the Project Name. Project Name should be without space and can contain alphanumeric characters. Enter the Package Name. It is optional. Ensure the Package name provided is valid. Click the OK button to create the New Project. By default the project created will make use of the Management Server in the 3 -Tier Architecture Mode and is Protocol Neutral.
Copy the xalan.jar, jaxp, and crimson.jar available in <Web NMS Home>/classes folder to another folder, example <Web NMS Home>/classes/endorsed_nms.
And include the statement "-Djava.endorsed.dirs=%WEBNMSHOME%\classes\endorsed_nms" in the java script in the <StudioHome>/ClientBuilder/setEnv.bat file as given below.
set JAVA_CMD="%JAVA_HOME%\bin\java" -Xmx200M -Djava.endorsed.dirs=%WEBNMSHOME%\classes\endorsed_nms
Setting Global Properties for the Wizard and the Project
To configure the Wizard settings select the menu Properties -->Global Properties or press F2. In the Global Properties dialog set the following properties :
Web Browser - The path where the binary executable file of the browser lies.
Bean Width Min - the minimum width for the bean components.
Bean Height Min - the minimum height for the bean components.
Screens in Memory - the maximum number of screens to be loaded in the memory of the Configuration Wizard at a particular instance.
Actions in Memory - the undo/redo action limit.
Error Log File- the file name to log the error messages.
Output Log File - the file name to store the 'System.out.println' messages if any.
Projects To Load - the projects to be loaded by default when the Wizard is invoked. The 'log' check box needs to checked to start logging in the log files mentioned.
Enable Screen Builder - By default, this check box is enabled and the Screen Builder is invoked while creating a new screen. If the user does not want to make use of this option, disable this check box. To invoke the Screen builder click on the New Screen icon in the toolbar or choose File --> New --> Screen menu item to create a new screen of build type Application, ignoring the Screen Builder.
Setting Properties for the Project
To set properties for the Project that is created select the menu Properties -->Project Properties or press F12 to invoke the Project Properties dialog. The properties that are available for setting are :
Look and Feel Standards:
The combo box has the following options:
AdventNet Look and Feel (ALF) Standards : Selecting this option will ensure all the screens designed follow the ALF (AdventNet Look and Feel ) standards. This will take effect only for the components that are dropped after the selection. The ALF standard is the default Look and Feel option selected for all the Client Builder projects. The motto behind the AdventNet Look & Feel Guidelines [ALF Guide] is to provide a standard look and feel for various AdventNet products. The Usability of a product is the one which interacts first with the user. Hence it is very important to consider the usability of the product while developing various components. AdventNet Look and Feel is the default interface for applications built with the Java Foundation Classes. The AdventNet look and feel is designed for cross-platform use and can provide:
Consistency in appearance and behavior of common design elements.
Compatibility with industry-standard components and interaction styles.
Aesthetic appeal that does not distract from application content and Feel is based on java UI standards, but it is specific to AdventNet Web NMS Studio - Client Builder.
User Defined Standards : Selecting this option enables the text field below the combo box. The name of the file specified here is the one to which the User defined standards are defined. By default the file chosen is Standards.alf present in <Client Builder Home>/builderdata directory. Now in the screen view, after dropping the bean component modify the bean properties to suit your UI taste using the Bean property form. To change the background to white, right click the bean and a pop-up menu appears where the menu item 'Add to Standards' is found. Click this to add the properties set for this bean to the 'User Look and Feel Standards File' (the file provided in the project property form- Standards.alf). The next time you drop a bean of the same type it will have the properties that you have added to the Standards File. In case you specify the name of a file that is not existing, the tool creates the file for you. In this way you can create files that contain standards specific to a project.
Warning: The ALFStandards.alf file is the AdventNet Look and Feel Standards file and the users are advised not to browse and select this file as the User defined Standards file, since this may cause damage to the tool. By default the Standards.alf file has properties that meet the ALF Standard. The ALF standards in this file are overwritten with the customized standards when the user-defined properties are set.
None : Selecting this option provides no option for the user to standarize the applications.
Contains the list of parameters and the corresponding
values to be used in an Applet or Application.
In the case of the Applet, enter the Applet Parameters and the generated HTML Document contains these parameter value pair.
In the case of Application, enter the command line arguments. The code required to parse these command line arguments are automatically generated.
Provide a brief description of the Project. Click the Edit Button to Invoke the Editor and enter the description.
Click OK to apply the changes to the Project.
Source Directory: The non editable text field displays the location of the generated source files for the current project.
Package Name: The displayed name is the name of the Project created at the time of creating the Project. The source generated for the project belongs to this package.
Internationalize the Source: Check the option to internationalize the source. Click the Locale Properties Button to invoke the Locale Properties dialog and provide the Locale Properties. The fields in Locale Properties dialog are
Variable Name: Enter the Variable name
used for getting the locale properties. By default it is set as "resourceBundle".
It can be changed as desired by the user. The source part generated with
this variable name is shown below as an example:
Bundle Name: This indicates the file name specifying the locale properties. By default, it is given as "<Project name>Resources". For example, for the project "default" the file name is "defaultResources".
Locale: This indicates the language
in which the words should be mapped to. On choosing the language, the
language extension is appended to the Bundle name which specifies the
locale file name. For example, the locale file name for the "default"
project is "defaultResources_ar_DZ".
To edit the locale properties,open the locale file in the form "BundleName_LocaleEditable.properties" present in <Client_Builder_Home>/Projects/<Your Project>/classes directory and make the necessary changes.
The locale file is <ProjectName>Resources.properties . So, if the name of the project is "default", the name of the locale file is defaultResources.properties. The <ProjectName>ResourcesEditable.properties and the <ProjectName>Resources.properties can be found in the classes directory of your project ( i,e in the <Home>/projects/<ProjectName>/classes ) directory. The ProjectName>ResourcesEditable.properties file is created with the English characters on the left side followed by a "=" and then the same characters in English as default. The user opens this file (Please make sure that you open the <projectName>Editable.properties file) and enters in the right hand side, the appropriate characters in the required language - say, Chinese. Then the source has to be regenerated using the Build --> Regenerate menu item When a regenerate is performed , the "native2ascii" command is executed and the UNICODE version of the characters is entered in the right hand side of the <ProjectName>Resources.properties file. Now , if the user Compiles the application and tests it ,he can find the application in the user specified language.
Click menu Build -> Regenerate for internationalization setting to take effect. The selected value for the Locale is set as a Project Parameter which is available in Project Properties in the 'General' Tab. The two parameters related to Internationalization are
RESOURCE_PROPERTIES that represents the Bundle Name and
RESOURCE_LOCALE that represents the Locale.
By making the required changes either in the Project Parameters or in the Locale Properties Dialog the generated source can be internationalized.
The purpose of native2ascii tool is to generate Unicode characters for a given set of characters in a file. To support intenationalization java expects all characters to be in Unicode format in the properties file. If the user is writing a Locale for JAPANESE properties file, then he cannot type in the Unicode values for each and every Japanese character. So what the Studio does is that it allows the user to enter his own Locale properties in a file called <ProjectName>Editable.properties. Using the native2ascii tool provided in the JDK the values in the <ProjectName> Editable.properties are converted to <ProjectName>.properties. This tool is run internally by the builder especially after each and every time the user regenerates the source. So after editing the <ProjectName>Editable.properties file, the user has to go and regenerate the source to execute this native2ascii tool. The user can also execute this tool manually using the command native2ascii <name>Editable.properties name.properties where the name stands for the combination of the <BundleName><Locale> So for the example cited above it will be defaultResources_ar_DZiEditable.properties and defaultResources_ar_DZi.properties respectively.
Drop a JLabel on to the Draw Area and in the "Property Form" specify the text value as "one".
In the "Project Properties" form, select the choice for "Internationalize the source" in the "Source Generation" tab..
Double click the "Locale Properties" button.
In the Locale Properties dialog change the locale to any language of your choice say ar_AE.
Confirm your choice by using the "OK" button to close the dialog and close the Project Properties form in a similar manner.
Click on "Regenerate" in the "Build" Menu
Go to the <Studio Chassis home>/projects/<ProjectName>/classes directory.
In the Editable.properties file edit the right hand side of "one = one " so that it is now changed to "one = this".
Save the file and then select the "Build" menu of the Studio Tool you are using.
Click Regenerate. This runs the native2ascii command.
Now you can "Compile and Run" the screen that contains the JLabel
Instead of "one", "this" will appear on the JLabel as text.
Note: This example explains you how to internationalize a screen, You can do this whole Project using the Project --> Regenerate Project.
The entries for the properties that need to be Internationalized can be edited, as illustrated and thus we have an "Internationalized" project.
Support Dynamic Parameter Change: Check this option to enable dynamic HOST and PORT parameters to be changed depending on the host in which the NAR application is invoked after installing the NAR (NMSPanel) in Web NMS.
classpath : Add the jars required for the Project.
Required jars : By default the APIUtils.jar and the JimiProClasses.zip are loaded and other Jars which are used in the Screens are also loaded. You can include any other jar from the jars directory of Client Builder Home.
Classpath : In the Classpath option you can include the classpath of the third party jars. This is applicable only for Application build types.
Append startup classpath : If it is enabled, the startup classpath of the tool is also added to the class path of the project. This again applies only to the Application Types.
Run Time Class Path Option : This path is provided to set the run-time class path. There are two radio options in this panel namely Compilation classpath and Smart Jar archive classpath.
Compilation Classpath : On choosing this option all the options provided in the Compilation classpath panel are considered.
Smart Jar Archive Classpath : If you select this option the classpath for jars provided in the "Smart Jar Options" dialog (it is invoked when you click the 'Smart Jar Archive Details' button) is considered.
Smart Jar archive Options : Press the Smart Jar Archive Details button. The Smart Jar Options dialog is invoked. The two tabs present are
Excluded Packages: Enter package prefixes of classes that need not be added to the "Smart Jar". For example, classes that start with "java." need not be added to the "Smart Jar" as these classes will any way be present in any JVM that the application/applet runs.
ClassPath: Enter the classpath for the application/applet. This is the classpath that will be set if the "Smart Jar archive classpath" option is selected in the Run Time classpath panel.
Click OK to apply the changes to the Project
The standard options provided by the Java Compiler to be made use of during the compilation of the project files are provides here. Check any of the below options based on requirements
Include Debug info - To generate debugging information.
Generate warnings - To generate warning messages.
Verbose Messages - To generate output messages about what the Compiler is doing.
Optimize - may hinder debugging or enlarge class file.
Show Deprecations - Give the location where deprecated APIs of Java are used in the source code.
The text field labelled "Classes Directory" displays the location of compiled classes are created. You can change this location if required.
Run Set up
Main Screen Name - This identifies the entry point for running the project i.e. the class corresponding to this screen is invoked first on running the project.
Java Home - Specify the path of JDK you want to test the application with. By default, the JDK path using which the Client Builder was started is specified here.
Java Parameters - Enter Java command-line Options, e.g. -verbose.
Java Variables - Specify the Variables whose values are specified by appending to the command while running.
Application Arguments - Specifiy the command line arguments needed for the Application Types. The difference between Application Arguments and the Project Parameters (in the General tab of Project Properties) is that in the case of Application Arguments, the parsing functionality is not incorporated in the generated code.
Test Screen as (Application/Applet) - The Management Application type depends on the Deployment to be made. This decides whether the Main Screen should be an Applet or Application. This warrants that the sub screens of type Panel, Frame and Dialog also behave the same way as the Main Screen. While Application can be chosen for Main Screen to be an Application and where it is necessary to avoid unnecessary caching of jars, Applet can be chosen to test the real Web related features.
Log Directory - Specifies the location of the logs directory of that project.
Log Application/Applet Output - Check this box to enable logging of application/applet output.
Use jdb - Specifies whether to run using "jdb" provided by JAVA.
Source Debug - Check this box to enable Source debugging.
MIBs to Load : Enter the Device Information files to be loaded. By default all the Device Information Files used in the Project are loaded and listed in this combo box.
Supported Protocols : The Protocols used in the current Project is listed. For eg if you load RFC1213MIB and display the sysName property in a bean, the SNMP would be listed in this Field.
Protocol Specific : On selecting this option the generated source shall have the Device Information related properties and instances specific to the 'Supported Protocols'.
Protocol Neutral : On selecting this option the generated Source is Protocol Neutral. By default this option is selected.
Management Server : The two options in this field are 3-Tier Architecture mode and 2-Tier Architecture mode. Choose any one from the following two modes:
3-Tier Architecture mode:A 3 Tier or multi-tier application constitutes the following - a data source (Database/Device), a business logic (Server) and a presentation layer (Client), To perform a specific function , each of these constituents interact among themselves. This architecture needs to have multiple clients operating on the data to share the management functions. The advantages of having a Multi Tier Application Architecture are
The traffic between the client and the data source is less because the business logic entity interacts only with the data source.
The presentation layer becomes thin as it does not process the data but just presents it .
The business logic can be pre configured to perform periodic functions like data collection and storage .
Enabling multiple views with the underlying data .
2-Tier Architecture mode: This is required when the business logic and presentation layer run as a single process In this mode the client application and the Management server run as a single process to interact with the managed device. The advantages of having this Architecture is
Direct communication with the device
The code generated for both the 2 and 3 Tier modes is as follows :
ms = com.adventnet.management.ManagementServicesAPI.getInstance(parameters, Integer.parseInt(getParameter("MS_MODE")));
where ms is the instance of the ManagementServices.
The getParameter("MS_MODE") will be replaced by the a value corresponding to the mode you have selected during run-time
By default the project will make use of the Management Server in the 3 -Tier Architecture Mode.
Click the 'OK' button to save the settings and close the Project Properties dialog.