Previous
Contents
Index
Next
|
| iPlanet BuyerXpert 4.5 Administrator's Guide |
Chapter 11 Configuration Files
There are many configuration files associated with iPlanet BuyerXpert. This chapter describes the files and provides instructions for doing some configuration tasks.
This chapter contains the following sections:
Master Configuration File
Configuring Additional Information Fields (AIFs)
Configuring Non-Catalog Fields
Configuring Intelligent Choosers
Controlling Growth of Workflow Log Table
Configuring for Attribute-Based Manager
Configurable OMS (omsConfig.ntv)
Rule Cache (omsRule.properties)
Tax (Resources, Setting Up Adjustments)
Customization/Localization Files
Note The application configuration files are the master.ntv file and the appInfo files.
Master Configuration File
The master configuration file of iPlanet BuyerXpert, master.ntv, can be found in the following locations:
APPS/com/iplanet/buyer/config
APPS/com/iplanet/buyer/admin/config
Note The name and location of the master.ntv file cannot be changed.
Both framework and application configuration information exists as a set of NTV structures (sections) in the master.ntv file. The sections are called:
Each of these structures is made up of one of several files residing in app-root/AppName/config.
The set of NTV files making up configuration the NTV files is determined by the following syntax in the master configuration file:
NTV {
"repository" StrArr [ "rep_common.ntv", "rep_oms.ntv", "rep_catalog.ntv" ],
"messages" StrArr [ "/ecommerce/arch/config/arch_msg.ntv", "msg.ntv",
"msg_oms.ntv" ],
"codes" Str "codes.ntv",
"appInfo" Str "appInfo.ntv"
}
This master file says that the repository is the result of merging of three NTV files, as well as the message NTV file. A file name like rep_common.ntv is relative to the application's configuration directory, which is app-root/appName/config, whereas an absolute path starting with / (slash) is relative to app-root. Since every AppName/config directory can contain multiple subdirectories, one for each supported locale, there should be a master.ntv file in each of them.
Sometimes it is helpful to have more than one configuration for a single application. For example, servlets developed exclusively for testing purposes may require special configuration (such as repository entries) which are not necessary for the real application. This is solved by having multiple master files; master.ntv for the real application configuration and master_test.ntv for testing.
To command the test servlet to use the test configuration, pass an additional URL parameter:
__Cfg=test
Note This value is kept in session data, so it is enough to pass it only once per session.
The extends and defaults attributes allowing you to specify inheritance relationships across NTV entries are supported for all configuration NTVs. Moreover, the semantics of extends is expanded so that cross-level inheritance is now possible. For example, the following NTV structure are expanded so that Node3 inherits Attr1 and Node4 inherits Attr2.
NTV {
"Node1" NTV {
"Attr1" Str "Value1"
},
"Node2" NTV {
"Node3" NTV {
"extends" Str ".Node1" // starts with "." meaning relative to the root
},
"Node4" NTV {
"extends" Str "A.B" // relative to the current level
},
"A" NTV {
"B" NTV {
"Attr2" Str "Value2"
}
}
}
}
When specified together, the extends attribute is processed before defaults. And file mergers (specified by master.ntv) are done before inheritance relationships are processed.
In the master.ntv file, the names of the different sections (repository, messages, and so on) cannot be changed. The ordering of the sections is not relevant.
The repository section lists all the DOR (Data Object Repository) files. The DOR files define the mapping between POF objects and Business Objects. The DOR files also act as a repository for UI elements such as text boxes, list boxes, and so on. More information on DOR files follows.
The messages section lists all the files that contain messages that get displayed in the user interface. More information on the messages files follows.
The codes section lists all the codes files. More information on the codes files follows.
The appInfo section lists all the configuration information for the different modules as well as the configuration information for the application itself. The application information is in a file called buyerInfo.ntv, which has to be the last in the list of appInfo files. This is to ensure that the entries in buyerInfo.ntv override any duplicate entries in the module-specific configuration files.
The data model section lists datamodel files. The data model specifies the types of POFs available for use by iPlanet BuyerXpert. It also specifies the mapping of the persistent objects to the data source schema.
Configuring Additional Information Fields (AIFs)
By default, AIFs are presented as text fields. You can change them into list boxes with predefined values by configuring certain NTV files.
The following scenario shows how to create a list box for a field named Size, with list box options of Small, Medium, Large, and Extra Large
Use the Admin interface to create an AIF called Size.
Modify the repository.ntv file located in following directory, adding an entry for the field Size:
$IASROOT/buyer/buyer/config/aif/repository.ntv
"Size" NTV {
"datatype" Str "String",
"type" Str "List",
"codecategory" Str "Size_options",
}
Modify the codes.ntv file located in the same directory, adding the list box options for Size as follows:
$IASROOT/buyer/buyer/config/aif/codes.ntv
"size_options" NTV {
"small" Str "Small",
"medium" Str "Medium",
"large" Str "Large",
"extra_large" Str "Extra Large",
}
Configuring Non-Catalog Fields
For non-catalog items, you can configure the fields for which information entry is mandatory. Exceptions to this are:
Estimated Price—Always mandatory. Users must enter some value.
Unit of Measure—Always mandatory. You can set a default value for the iPlanet BuyerXpert instance. The fields configured to be mandatory have a blue star (*) symbol displayed against them. This symbol is configurable.
To make a non-catalog field mandatory, follow these steps:
Modify the following file:
<IAS_ROOT>/buyer/buyer/config/oms/omsInfo.ntv
Modify the NTV of a particular non-catalog field to set "optional" to false. This makes the field mandatory. For example:
"Product Code" NTV {
"optional" Bool "true",
"default" Str "MyCode",
},
To configure the symbol displayed against a mandatory field, follow these steps:
Modify the following file:
<IAS_ROOT>/ias/APPS/buyer/com/iplanet/buyer/templates/en/US/catalog /EnterEntry.jsp
Note The above file is for the en/US locale. For other locales, replace en/US appropriately.
For configuring the symbol displayed against the Product Code field, look for the following section:
<% if (!Config.getBool("NonCatalog.Product Code.optional")) { %>
<!-- begin required marker -->
<font size="+2" color="blue"><tt><b>*</b></tt></font></td>
Modify the parameters for font size, color, and symbol. For example, to display a # symbol against a mandatory field in red, with a font size of 3, you would change the above section as follows:
<% if (!Config.getBool("NonCatalog.Product Code.optional")) { %>
<!-- begin required marker -->
Configuring Intelligent Choosers
To configure a particular chooser to provide drop-down list, follow these steps:
Modify the following NTV file:
<IAS_ROOT>/buyer/buyer/config/oms/chooser.ntv
For an NTV of a particular chooser, set the value for maxShortList. When the possible values to choose from for this field is less than the set number, a drop-down list is generated. For example, for the line item accounting code chooser, set maxShortList to 20 and set dropDownList to True.
"LineAccountingCodeChooser" NTV {
"title" Str "Accounting Codes Chooser",
When the possible values for an accounting code segment are less that 20, a drop-down list displaying those values is generated for that accounting code segment. If the possible values are more than 20, the segment displays a chooser as it did in iPlanet BuyerXpert 4.0. If you want to display a drop-down regardless of the possible values for the accounting code segment, then set maxShortList to -1
If you do not want dropdown list under any circumstances, set dropDownList to false. In that case, iPlanet BuyerXpert always displays chooser, and the value set to maxShortList is used as explained in the following example:
"LineAccountingCodeChooser" NTV {
"title" Str "Accounting Codes Chooser",
If the possible values for an accounting code segment are less than 200 (value set to maxShortList), then a chooser initially displaying first 10 (value set to pageSize) of the possible 200 values is generated.
You can display more or less values by changing the value of pageSize. If the possible values for the accounting code segment are more than 200, a chooser with no initial values is displayed. When a user does a search for codes using the normal or advanced search, results is displayed in sets of 10 (value set to pageSize) per page. You can display more or fewer values for the search result by changing the value of pageSize.
To force to chooser to behave like iPlanet BuyerXpert 4.0, set the maxShortList to 0. To force it to turn it into a drop-down list, set maxShortList to -1.
Controlling Growth of Workflow Log Table
The Admin can control the growth of the workflow log table with the help of an .ntv file named wfLog.ntv. The file appears as follows:
"SUBMITTED_TO_WF_EVENT" Bool "true",
"ENTER_INBOX_EVENT" Bool "false",
"ESCALATE_EVENT" Bool "false",
"REASSIGN_EVENT" Bool "false",
"GATECHECK_ENTER_EVENT" Bool "false",
Whether to log, or not to log, is determined by the boolean flag against individual events. By turning these flags ON/OFF, the customer can control the log into the workflow_log table.
Configuring for Attribute-Based Manager
By default, iPlanet BuyerXpert associates managers for users through the organizational unit. It is also possible to associate manager information with individual users as an attribute of the user, as opposed to the indirect representation through organizational units.
To enable attribute-based manager functionality, you must toggle the config setting in the following NTV file as shown:
<iasroot>/buyer/config/com/iplanet/ecommerce/membership/config/appInfo.ntv.
...
// defaulted to false for the org unit based manager
"useManagerAttr" Bool "true",
...
},
}
This enables administration of the manager from the user identification screen and as a user attribute when using the Import utility.
By default, the approval process is set to walk the manager chain through organizational units. When using the attribute-based manager, you might need to configure the approval process also to the attribute-based manager chain.
Launch the Builder.sh application from the <IASROOT>/builder/ directory.
Open the prototype_req_BuyerCompany application.
Open the calc_manager_approval function located under Scripts Dictionary/Automation Scripts.
var manager = req.getManager(creator.getHandle(), 1, false);
(The last parameter value, false, gets managers from the organizational unit chain.)
Change this line to:
var manager = req.getManager(creator.getHandle(), 1, true);
(The last parameter value, true, gets managers based on user attribute.)
After making the change, click OK.
For these changes to take effect, deploy the process by clicking Deploy.
Application Info Files
The application information (appInfo) files are used by the different components to store configuration information. Most of this information cannot be changed.
For example, the order management system stores the criteria for splitting a requisition into purchase orders in the lguConfig.ntv file. The information in this file cannot be changed. However, xdoc stores some information in the following file, which is configurable:
ias/APPS/com/iplanet/buyer/config/xdoc/xdocinfo.ntv
Some of the appInfo files that you will be configuring include:
buyerInfo.ntv
buyerInfo.ntv
The most important appInfo file is buyerInfo.ntv. This file deserves more explanation, because it contains application configuration information with which the administrator has to be familiar.
Here is how a sample buyerInfo.ntv looks:
"on_auth_error" Str "NonAuthTemplate.jsp",
"params_for_exceptions" Bool "true", // exception params in log file
"stack_for_exceptions" Bool "true", // stack trace in log file
"stack_top_ignore" StrArr [ "CXDebug.", "CXReporting." ],
"stack_bottom_cut" StrArr [ "BeanLogic.execute", "CXBaseServlet.do" ],
}, // End of default message_type
"active" Bool "false", // disabled for now. will enable later.
"params_for_exceptions" Bool "true", // exception params in log file
"stack_for_exceptions" Bool "true", // stack trace in log file
"stack_top_ignore" StrArr [ "CXDebug.", "CXReporting." ],
"stack_bottom_cut" StrArr [ "BeanLogic.execute", "CXBaseServlet.do" ],
}, // End of default message_type
"data_source" Str "jdbc/default",
"data_source" Str "jdbc/default_tx",
"data_source" Str "pinevalley",
"user_name" Str "cn=Directory Manager",
"attr_server" NTV { // this section is to overwrite the
// default attribute server connection defined
// in /ecommerce/attrsvr/config/appinfo
// uncomment out the following for changes
"data_source" Str "jdbc/rules", // use separate connection for performance
// "data_source" Str "jdbc/default",
"tx_source" Str "attr_server_tx",
"optimizer_max_permutations" Int "1000"
"attr_server_tx" NTV { // this section is to overwrite the
// default attribute server connection defined
// in /ecommerce/attrsvr/config/appinfo
// uncomment out the following for changes
"data_source" Str "jdbc/rules_tx", // use separate connection for performance
// "data_source" Str "jdbc/default",
"attr_server" NTV { // this section is to overwrite the
// default attribute server schema prefix
// in /ecommerce/attrsvr/config/appinfo
// uncomment out the following for changes
"root_dn" Str "o=iplanet.com",
"data_source_access" Str "com.iplanet.ecommerce.membership.util.AuthDataSourceAccess"
Some appInfo entries are reserved for use by the framework:
on_auth_error (String)—A name of the JSP template to be used for displaying an appropriate message when all the user authentication information is lost (this can happen when a user session expires). The value of this attribute could also be an absolute URL of a servlet. In this case, this servlet is redirected when an authentication problem occurs.
log (NTV)—Settings related to logging (the default reporting mechanism, the logging locale and message filters). These settings control the behavior of the CXReporting.report method.
trace (NTV)—Parameters related to tracing (the trace stream definition, message filters and settings defining the volume of information directed to the trace stream). This entry controls the behavior of the CXDebug.trace method.
data_sources (NTV)—Configuration for data sources used by the application.
object_space (NTV)—Additional configuration for data sources used by POF.
data_source_access (Str)—The fully qualified name of the Java class performing application-specific connection management. This class should be derived from com.iplanet.ecommerce.arch.CXDataSourceAccess.
attr_server (NTV)—Data needed to instantiate an attribute server. This NTV contains the following values:
The datasources section lists the data stores that are used by the application. The RDBMS datasources have to be registered with the Application Server using the resreg utility provided by iAS.
The datasource format is as follows:
DataSources := "data_sources" NTV { <DataSourceStanzas> }
DataSourceStanzas := "<name>" NTV {
"type" Str "<DataSourceType>",
"data_source" Str "<dataSourceName>",
[ "user_name" Str "<jdbcUserName>", ]
[ "password" Str "<jdbcPassword>", ]
Details related to the data_sources, object_space and data_source_access entries can be found in the POF documentation.
To avoid name collisions, each functional module is given a subtree in the appInfo NTV, configuration data specific to the module should be placed in this subtree. For example:
Tracing-Related Settings
The attributes mentioned in this section are specified inside the trace entry of the appInfo NTV. All attributes are set on the per message type basis. Namely, the trace entry typically looks like the following:
// settings for the "perf_trace" message type
// settings for the "default" message type
The active, reporter and filter attributes have the same syntax and semantics as they have inside the log entry. There are also other attributes defining the volume of information directed to the trace stream:
params_for_exceptions (boolean)—If set to true and an instance of CXException is passed to CXDebug.trace, an NTV containing exception parameters is written to the trace stream.
stack_for_exception (boolean)—If set to true and an instance of Throwable is passed to CXDebug.trace, its stack trace is written to the stream.
stack_for_all (boolean)—Like the above, but the stack trace is written for all calls of the trace method (even if the object passed is not the exception. In this case, the stack trace relates to the point at which the method is called).
stack_top_only (boolean)—If set to true, only the first (topmost) line of the stack trace is printed.
stack_top_ignore (StrArr)—This attribute is used to reduce the amount of unnecessary information placed to the trace stream. When a stack trace is printed, its topmost lines containing either element of this array as a substring are suppressed. The usual value is ["CXDebug.", "CXReporting."].
stack_bottom_cut (StrArr)—This attribute serves the same purpose as the one above. If a line of a stack trace contains either element of this array, this line as well as all lines below it are suppressed. The usual value is ["BeanLogic.execute", "CXBaseServlet.do"]. The filter attribute is mostly the same as inside the log entry. The difference is that it is possible to specify volume settings (except stack_top_ignore and stack_bottom_cut) on the per filter element basis. For example, the following filter element is prescribed to write out exception parameters for all errors of the catalog module:
"params_for_exceptions" Bool "true"
Per-element volume settings take precedence over the common ones. If a tracing message meets multiple filter conditions, the message is printed out as if their volume settings were united.
mail.ntv File
The ias/APPS/com/iplanet/ecommerce/workflow/config/mail.ntv file is listed below:
The sender should contain a valid user ID and smtphost should contain a valid smtp host name. These entries are used to form an email address as follows: sender@smtphost.
This email address is used for sending email notifications.
Configuring for Approvers Who Use Microsoft Outlook 97
For Microsoft Outlook 97 users to be able to approve requisitions without logging into BuyerXpert, the HTML format email is sent as an attachment, allowing approvers to open the attachment from Outlook 97
To implement this, the following new entries must be made into the mail.ntv file:
...
"inLineText" Bool "true", //want inline text in mail (true/false)
"inLineTextMessage" Str "Message body not found. Contact Administrator for detail.", //when inLineText is false, message u would like have in mail
"Attachment" NTV { //for attachment
"urlAttachment" Bool "false", //want url attachment (true/false)
"fileAttachment" Bool "false", //want file attachment (true/false)
"attachmentName" Str "Click here for the form", //attachment
caption
xdocinfo.ntv File
The ias/APPS/com/iplanet/buyer/config/xdoc/xdocinfo.ntv file is listed below:
"xdoc_dir" Str "$ECX_HOME/bin",
"submit_to_ecx_script_850" Str "submitToECX_850.sh",
"submit_to_ecx_script_860" Str "submitToECX_860.sh",
"submit_timecard_to_ecx_script" Str "$ECX_HOME/bin/submitTimecardToECX.sh",
"timecard_receiver" Str "legacyTC", //
"timecard_sender" Str "buyerTC", //
"timecard_filetype" Str "timecard",
"timecard_file" Str "timecard.xml",
"xdoc_archive_dir" Str "/tmp",
"smtphost" Str "smtphost.buyerhost.com",
"subject" Str "Status change in BuyerXpert",
"url" Str "http://<BuyerHost>:<BuyerPort>/NASApp/buyer/"
"cc" Str "admin@buyerhost.com"
"status_message" Str "BuyerXpert status change. Please contact your admin"
"inbound_error_message" Str "Error processing the inbound request. Please contact your
"po_transmission_failure" Str "Transmission of the PO failed. Please contact your
"cancel_transmission_failure" Str "Transmission of the PO cancellation failed. Please
There is a script that configures xdoc for outbound documents. Run the script:
IAS-ROOT/buyer/sample_data/xdoc/scripts/config_xdoc.pl
This script does the necessary updates to the preceding configuration file.
omsServiceInfo.ntv File
The ias/APPS/com/iplanet/buyer/oms/omsServiceInfo.ntv file is listed below:
//** com/iplanet/buyer/attachment is a link entry of "/tmp"
directory and should reside at web server docs directory
"file_system_entry" Str "/tmp",
"web_entry_link" Str "com/iplanet/buyer/attachment"
The "file_system_entry" specifies the physical location where attachments for notes reside. This value is configurable.
reportsInfo.ntv File
If you have the Actuate server running on one machine and iPlanet BuyerXpert and the Oracle instance running on another machine, you need modify Acutate_Path to point to a running Actuate server.
Go to the IAS_HOME/buyer/buyer/config/reports directory.
Edit the reportsInfo.ntv file by modifying Actuate_Path to point to a running Actuate server. For example:
http://colonial.red.iplanet.com:5050/acweb/colonial
Verify that linkto is pointing to your iPlanet BuyerXpert URL.
Log into the machine that is running the Actuate server and add the Oracle instance that the client machine points to in the tnsnames.ora file.
Create a file, such as bx_input.txt, that contains the user name, password, and ORACLE_SID that iPlanet BuyerXpert is using on the client machine.
In the reportsInfo.ntv file, enter this file in the actuate_login field.
Restart the iPlanet Application Server:
omsInfo.ntv File
The order management NTV file specifies the number of requisitions and timecards to be displayed per page. For example, on the Track screen.
The off-catalog NTV file is for the off catalog screen items. It specifies whether or not the off-catalog screen is optional, the default value, and the validation model.
By setting the ShowCheckoutConfirmation to False, the Confirm Checkout screen is bypassed.
The reqState NTV file specifies the display strings that correspond to the states of a requisition. For example, a requisition state is displayed at Pending Approval if the status of the requisition is PENDING_APPROVAL.
The ias/APPS/com/iplanet/buyer/oms/omsInfo.ntv file is listed below:
NTV-ASCII {
"NonAuthTemplate" Str "NonAuthTemplate.jsp",
"default_uom" Str "each",
"defReporter" NTV {
"reporter" Str "Printout"
},
"oms" NTV {
"ordersPerPage" Int "5",
"requisitionsPerPage" Int "5",
"timecardsPerPage" Int "2",
},
"offCatalog" NTV {
"defaultUnit" Str "each",
"defaultQty" Dec "1",
},
"NonCatalog" NTV {
"Product Code" NTV {
"optional" Bool "true",
"default" Str "",
},
"Product Description" NTV {
"optional" Bool "false",
"default" Str "",
},
"Commodity Code" NTV {
"optional" Bool "true",
"validation" Bool "false",
"default" Str "",
},
"Supplier" NTV {
"optional" Bool "true",
"validation" Bool "false",
"default" Str "other",
},
"Quantity" NTV {
"optional" Bool "true",
"default" Dec "1",
},
"UOM" NTV {
"validation" Bool "false",
"default" Str "each",
},
},
"HostCompany" Str "BuyerCompany",
"UnknownCompany" Str " Unknown Seller Company ",
"MaxLength" Int "20",
"ReqNamePrefix" Str "Req - ",
"CopyString" Str "Copy of ",
"ReorderString" Str "Reorder of ",
"TemplateString" Str "Template - ",
"Req" Str "Requisition",
"Template" Str "Template",
"PO" Str "Purchase Order",
"ANY" Str "Any",
"ALL" Str "All",
"ShowCheckoutConfirmation" Bool "true",
"reqState" NTV {
"-" Str "All",
"CREATED" Str "Created",
"PENDING_APPROVAL" Str "Pending Approval",
"APPROVED" Str "Approved",
"DECLINED" Str "Declined",
"WITHDRAWN" Str "Withdrawn",
"CANCELLATION_TRANSMITTED" Str "Cancel Transmitted",
"PARTIALLY_CANCELLATION_TRANSMITTED" Str "Partially Cancellation Transmitted",
"FAILED_CANCEL_TRANSMISSION" Str "Failed Cancel Transmission",
"PARTIAL_ACKNOWLEDGED" Str "Partially Acknowledged",
"CANCELLED" Str "Cancelled",
"CANCEL_REJECTED" Str "Cancel Rejected",
"ORDER_REQUESTED" Str "Order Requested",
"ORDER_TRANSMITTED" Str "Order Transmitted",
"FAILED_ORDER_TRANSMISSION" Str "Failed Order Transmission",
"PARTIAL_RECEIVED" Str "Partially Received",
"RECEIVED" Str "Received",
"PARTIAL_INVOICED" Str "Partially Invoiced",
"INVOICED" Str "Invoiced",
"PARTIAL_SHIPPED" Str "Partially Shipped",
"SHIPPED" Str "Shipped",
"CLOSED" Str "Closed",
"ORDER_REJECTED" Str "Order Rejected",
"ACKNOWLEDGED" Str "Acknowledged",
"DELIVERED" Str "Delivered",
},
"defaultUnit" Str "each",
}
Data Model Files
This section describes the data/object configuration files, which are dataModel files and DOR (Data Object Repository) files.
The configuration that you would have to do in the data model is related to xdoc. When xdoc is configured for non-OBI, then there are some custom properties in the dataModel that determine which attributes of a purchase order are to be written out for sending to the vendor. Here is an example of this custom attribute:
"class_name" Str "order_header",
"attr_name" Str "need_by_date",
"schema_attr" Str "need_by_date"
The above example shows that the order_id attribute of a requisition should not be written out while writing out an outbound purchase order, whereas the "need_by_date" needs to be written out.
The above example shows how attributes of a given object can be selectively written out during xdoc. You can also specify the "PurchaseOrder" custom_property for relationships. This allows us to say "if line_group is written out then line objects associated with line_group also have to be written out." Of course, while writing out the line object, the "PurchaseOrder" custom property for each attribute of the line_group is examined. Only those attributes which have "PurchaseOrder" = true are written out.
An example of the custom_prop for a relationship is given below:
"data_object" Str "line_group",
"assoc_rel" Str "line_group_lg_line_assocs",
"access_name" Str "line_groups",
"assoc_rel" Str "line_lg_line_assocs",
The PurchaseOrder custom property is examined while writing out purchase orders sent to the vendor. Similarly, there is another custom property called OrderChange which is used to determine the objects and attributes that are to be sent to a vendor for an "Order Cancellation Request."
DOR Files
The repository is an NTV structure (physically existing as a set of files in app-root/AppName/config) that defines categories of data items that can be input and/or output by the application. Each category is represented by a single entry that looks like the following:
...... optional attributes go here ....
"productQuantity" is a data item name (which can be referred to by PC scriptlets).
"datatype" is a mandatory attribute defining the domain of valid values and the way of transforming those values from native format to external representation and vice versa.
"Int" means the domain of integer numbers. Native type int and the standard conversions between integers and strings.
"type" is another mandatory attribute, defining how to construct HTML UI controls through which you can enter a value of the data item.
"Text" denotes the HTML input field as a way of entering values. In general, the roles of "type" and "datatype" can be described as follows:
At page generation time: The datatype is used to convert the default value of a data element from its native format to external representation. The type is used to build HTML UI element(s) so that their initial appearance corresponds to the external representation.
At form submission time: The Web browser, Web server and iAS infrastructure guarantee that the external representation of user input is delivered to the application.The datatype is used to validate the external representation delivered and to convert it back to native format. Another responsibility of the datatype is generating a descriptive error message provided the user input is not valid.
Type and datatype are fully orthogonal. UI elements that are generated based on types deal with external representations only and have nothing to do with the native data formats, which are taken care of by datatypes.
The set of possible types and datatypes is not something hardcoded in the CX framework. Indeed, the CX 4.0 architecture provides a relatively easy way to introduce new types and datatypes.
Business objects are also reflected in the repository (hence its name, Data and Object repository). For a simplified business object user having two attributes (Name and Password), the repository entry looks like the following:
Configurable OMS (omsConfig.ntv)
In BuyerXpert 4.5, certain functionality can be turned ON/OFF to improve performance. In the $IASROOT/buyer/buyer/config/oms/omsConfig.ntv file, the following attributes can be modified:
EVAL_MODEL
DCAP
SHIPPING
TAX
For example:
If you use the PriceList model without DCAP, SHIPPING, or TAX, you can set the parameters in the NTV file to turn off these three functions as follows:
When you disable a functionality, remove the corresponding rules from the Rule Cache (omsRule.properties file).
For the preceding example, you can exclude those rules related to DCAP, SHIPPING, and TAX in the CACHE_RULES property file.
Rule Cache (omsRule.properties)
In BuyerXpert 4.5, performance of the order management system (OMS) can be improved by resetting the RULE_REFRESH_INTERVAL in the omsRule.properties file. This is the time interval for refreshing the rules from the database. For instance, if RULE_REFRESH_INTERVAL = 20, when you modify a rule in the iPlanet BuyerXpert Admin interface, the change is reflected in iPlanet BuyerXpert within 20 minutes.
The CACHE_RULES property in the $IASROOT/ias/APPS/omsRule.properties file lists the list of rules that are cached.
Tax (Resources, Setting Up Adjustments)
Tax adjustments that need to be configured through administration are as follows:
ship_to_location.region, ship_to_location.major_locality,
ship_from_location.region, ship_from_location.major_locality, line.tax_code
String
Results
Amount, Percentage
Percentage => line.net_taxable_amount (Tax Table)
line_dcap.amount ( DCAP Tax Table )
line_freight.amount ( Freight Tax Table )
Amount => No Target.
Lookup Table
( (>= x, v1), (>=y, v2), (>=z, v3))
Voters: value ` -ALL-' for each Voter.
Tax Model: INTERNAL
Freight Tax Table : line-level tax charge adjustment sample 9 (#509)
Tax Table : line-level tax charge adjustment sample 1 (#501)
DCAP Tax Table : line-level tax charge adjustment sample 9 (#509)
Tax Adjustment #501
Source: ship_to_location.region
Results: PERCENTAGE
Results Apply To: line.net_taxable_amount
Look up Table: ( (West Coast, 8.25), (East Coast, 10), (other, 20) )
Tax Adjustment #509
Source: line.tax_code
Result: PERCENTAGE
Look up Table: ( (65000, 8.25), ( 65005, 10), (other, 20) )
TAX ADJUSTMENT: Group Level
Adjustment
ship_to_location.region, ship_to_location.major_locality,
ship_from_location.region, ship_from_location.major_locality,
line_group.tax_code
Source Unit
String
Results
Amount, Percentage
Percentage =>line_group.group_dcap ( DCAP)
line_group.group_freight ( Freight )
Amount => No Target.
Lookup Table
( (>= x, v1), (>=y, v2), (>=z, v3))
Customization/Localization Files
This section describes the customization/localization configuration files, which are messages files and codes files.
Messages File
A typical messages.ntv file looks similar to the following:
"Adjustment:NoAttr" Str "No Attributes received by import for Adjustment.",
"Adjustment:OperationFailed" Str "Ajustment import operation failed.",
As part of any localization effort, the message itself can be customized. The message code (for example, "Adjustment:NoAttr") should not be changed.
Codes File
The codes file allows you to define static lists of data which display in pull-down lists in the user interface. A pull-down list allows users to choose an item from the list rather than typing it in. Typical lists are all states or all countries.
The following codes.ntv file lists the states and their abbreviations as well as the countries and their abbreviations.
Note It is important to use the correct state and country abbreviations when mapping for pull-down lists or the Import utility.
"AA" Str "Armed Forces Americas",
"AE" Str "Armed Forces Europe",
"AP" Str "Armed Forces Pacific",
"DC" Str "District Of Columbia",
"MP" Str "Northern Mariana I",
"AE" Str "United Arab Emirates",
"AG" Str "Antigua and Barbuda",
"AN" Str "Netherlands Antilles",
"BA" Str "Bosnia and Herzegovina",
"DO" Str "Dominican Republic",
"FX" Str "Metropolitan France",
"GW" Str "Guinea-Bissau - Guine-Bissau",
"HM" Str "Heard Island and McDonald Islands (Australia)",
"HR" Str "Croatia - Hrvatska",
"HU" Str "Hungary - Magyarorszag",
"IO" Str "Indian Ocean Territory (UK)",
"KH" Str "Cambodia - Kampuchea",
"KN" Str "Saint Kitts and Nevis",
"LB" Str "Lebanon - Lubnaniyah",
"LT" Str "Lithuania - Lietuva",
"MK" Str "Macedonia - Makedonija",
"MN" Str "Mongolia - Mongol Uls",
"MP" Str "Northern Mariana Islands",
"MQ" Str "Martinique (France)",
"MR" Str "Mauritania - Muritaniyah",
"MZ" Str "Mozambique - Mocambique",
"NC" Str "New Caledonia - Nouvelle-Caledonie",
"NF" Str "Norfolk Island (Australia)",
"NL" Str "Netherlands - Nederland",
"PF" Str "Polynesie Francaise",
"PH" Str "Philippines - Pilipinas",
"PM" Str "Saint-Pierre et Miquelon",
"SG" Str "Singapore - Singapura",
"SI" Str "Slovenia - Slovenija",
"SJ" Str "Svalbard og Jan Mayen",
"SK" Str "Slovakia - Slovensko",
"ST" Str "Sao Tome e Principe",
"SU" Str "Soviet Union - Sovietskiy Soyuz",
"TC" Str "Turks and Caicos Islands",
"TF" Str "Southern and Antarctic Lands",
"TJ" Str "Tajikistan - Tojikiston",
"TK" Str "Tokelau (New Zealand)",
"TM" Str "Turkmenistan - Tiurkmenostan",
"TT" Str "Trinidad and Tobago",
"UA" Str "Ukraine - Ukrayina",
"UM" Str "United States Minor Outlying Islands",
"US" Str "United States of America",
"UZ" Str "Uzbekistan - Uzbekiston",
"VC" Str "Saint Vincent and the Grenadines",
"VG" Str "Virgin Islands (UK)",
"VI" Str "Virgin Islands (USA)",
"VN" Str "Vietnam - Viet Nam",
Previous Contents Index Next
Copyright © 2002 Sun Microsystems, Inc. All rights reserved.
Last Updated June 10, 2002