| Oracle® Retail POS Suite Implementation Guide, Volume 2 – Extension Solutions Release 14.1 E54476-02 |
|
 Previous |
 Next |
| Oracle® Retail POS Suite Implementation Guide, Volume 2 – Extension Solutions Release 14.1 E54476-02 |
|
Previous |
Next |
Customers who purchase Point-of-Service extend the product to meet their particular needs. These guidelines speed implementation and simplify the upgrade path for future work.
Developers on customer projects should also refer to the Development Standards. The Development Standards address how to code product features to make them less error-prone and more easily maintained. They are especially important if code from the customer implementation may be rolled back into the base product.
|
Note: See the Oracle Retail POS Suite Security Guide for more information about specific security features and implementation guidelines for the POS Suite products. |
This section describes conventions used throughout this chapter.
The following definitions are used throughout the chapter:
Product source tree — A directory tree that contains the Oracle Retail product code. The contents of this tree do not change, with the exception of product patches. In production code, these files are accessed as external .jar files.
Customer source tree — A directory tree separate from the product code that contains customer-specific files. Some of these files are new files for customer-specific features; others are extensions or replacements of files from the product source tree. The customer tree should not contain packages from the product tree.
Customer abbreviation — A short name that represents the customer. For example, a company named My Bike Store might use MBS as their customer abbreviation. The MBS example is used throughout this chapter; replace MBS with the customer abbreviation for your own project when writing code. The customer abbreviation is added to filenames to clarify that the file is part of the customized code, and is used as part of the package name in the customer source tree.
Filenames in the customer source tree usually include the customer abbreviation. Name files according to the following rules:
If a class in the customer source tree extends or replaces a class in the product source tree, use the customer abbreviation followed by the original filename as the new filename (for example, SaleReceipt.java becomes MBSSaleReceipt.java).
New Java classes should also begin with the customer abbreviation.
Script or properties file names that are hard-coded in Foundation classes must use the same filename in the customer source tree as was used in the product source tree (for example, posfoundation.properties).
The Point-of-Service system is divided into a number of different modules, and each module corresponds to a project in an integrated development environment (IDE). When setting up a development environment for modifying code, building Point-of-Service, and testing changes, you must configure your system to make MBSpos dependent on all the other modules.
Do the following to set up your development environment:
Check out each of the required customer modules as shown in the following table.
Reference each of the standard modules as external .jar files.
Add the required modules to your CLASSPATH environment variable in the order shown in the following table, with all of the customer modules preceding the set of standard modules.
Table 5-1 identifies required customer and standard modules in their respective dependency orders.
Table 5-1 Required Modules in Dependency Order
| Customer Modules | Standard Modules |
|---|---|
|
MBS pos (root, src, locales and other language directories)Foot 1 MBS domain (root and src) MBS commerceservices MBS common MBS 3rd-party MBS utility MBS exportfile |
pos (root, src, locales and other language directories) domain (root and src) common commerceservices foundation 3rd party utility exportfile |
Footnote 1 Directory names in parentheses must be specified individually in the classpath.
Paths given in this chapter are relative, starting either with the module or with the source code, as follows:
Paths beginning with a module name start from the module location. pos\config refers to the config directory within the pos module, wherever that module is located on your system.
Paths beginning with com refer to source code. Source code paths are nested within modules, in \src directories. Multiple \src\com file hierarchies are built together into one file structure during compilation. For example, a reference to oracle\retail\stores\pos\services\tender can be found in the pos module's src directory. If your pos module is in c:\workspace\OracleRetailStore, then the full path is:
C:\workspace\OracleRetailStore\applications\pos\src\oracle\retail\stores\pos\services\tender
This section addresses extension of files in the POS package.
|
Note: The POS module might be nested within an OracleRetailStore directory in the source code control system. |
You extend tours mainly by editing proprietary XML scripts developed by Oracle Retail. This section describes how to customize tours, beginning with replacing the Tour Map, and continuing with customization of individual tours or parts of tours.
The product code references tours at transfer stations by logical names, so that you can change a single tour without having to update references to that tour in various tour scripts. Tour maps tell the system the specific tour files to use for each logical name.
The tour map also enables overlays of tour classes. If a tour script does not need to be customized, but some of the Java classes do, the tour map can specify individual classes to customize. Note that any class files must still use their own unique names (such as MBScashSelectedAisle.java for a new Aisle used in place of CashSelectedAisle.java).
Typically, the base product Tour Map file, tourmap.xml, does not change. Instead, you create a custom Tour Map for your project. This Tour Map file contains only the differences it adds to the base Tour Map.
Do the following to add new Tour Map files:
Create one custom Tour Map file in the pos\config directory of the customer source tree. Initially, this Tour Map file may be empty; as you customize tour components, you can add tags.
Copy the pos\config\posfoundation.properties file to the customer source tree. Modify the tourmap.files property in this file, adding the names of the new Tour Map files. Do not rename the posfoundation.properties file, since this filename is referenced by Foundation classes. It is important to keep the customized tour map files after the product tour map file in the list, since the files listed later override earlier files.
Refer to the procedures that follow to modify tour scripts and Java components of a tour.
If you need to change the workflow of a tour, you must replace the tour script; you cannot extend a tour script. To replace a tour script, follow these steps:
Create a new XML tour script in the customer source tree.
Modify the tour map in the customer source tree to specify the correct package and filename for the new tour script. The logical tour name must stay the same.
Copy and modify sites, roads, aisles, shuttles and signals.
Extending siteactions in the traditional object-oriented sense is not recommended; letters mailed in the original arrive method would conflict with the arrive method in the extended class. Since siteactions represent relatively small units of code, they should be replaced instead of extended. Perform these steps:
Create a new siteaction class in the customer source tree, such as MBScashSelectedSite.java.
If you are overlaying a siteaction class, but not modifying the tour script, then all letters that were mailed from the product version of the siteaction class should also be mailed from the new version. Do not mail new letters that are not handled by the product code, unless the tour script and related Java classes are also modified.
Edit the appropriate Tour Map, using the replacewith property in the <SITEACTION> tag to define the new package and filename for the siteaction class.
Example 5-3 MBStourmap.xml: Replacing a siteaction
<tour name="tender">
<file>classpath://com/mbs/pos/services/tender</file>
<SITE
name="cashSelected"
useaction="oracle.retail.stores.pos.services.tender.cashSelectedSite"/>
<SITEACTION
class="cashSelectedSite"
replacewith="com.mbs.pos.services.tender.MBScashSelectedSite"/>
</tour>
As with siteactions, extending laneactions in the traditional object-oriented sense is not recommended, as letters from the original and extended classes could conflict. Do the following to replace laneactions instead of extending them:
Create a new laneaction class in the customer source tree, such as MBSOpenCashDrawerAisle.java.
If you are overlaying a siteaction class, but not modifying the tour script, then all letters that were mailed from the product version of the laneaction class should also be mailed from the new version. Do not mail new letters that are not handled by the product code, unless the tour script and related Java classes are also modified.
Edit the appropriate Tour Map using the replacewith property in the <LANEACTION> tag to define the new package and filename for the laneaction.
Example 5-4 MBStourmap.xml: Replacing a laneaction
<tour name="tender”>
<file>classpath://com/mbs/pos/services/tender</file>
<SITE
name="RefundDueUI"
useaction="com.mbs.pos.services.tender.refundDueUISite">"/>
<LANEACTION
class="OpenCashDrawerAisle"
replacewith="com.mbs.pos.services.tender.MBSOpenCashDrawerAisle"/>
</tour>
Since shuttles do not mail letters, they may be extended or replaced; however extending them is recommended. Do the following to either extend or replace shuttles:
Modify the shuttle class.
Create a new class in the customer source tree. If it extends or replaces the product bean class, add the customer abbreviation to the filename. For example, TenderAuthorizationLaunchShuttle.java becomes MBSTenderAuthorizationLaunchShuttle.java.
Edit the appropriate Tour Map using the replacewith property in the <SHUTTLE> tag to define the new package and filename for the shuttle.
Example 5-5 MBStourmap.xml: Replacing or Extending a shuttle
<tour name="tender”>
<file>classpath://com/mbs/pos/services/tender</file>
<SITE
name="RefundDueUI"
useaction="com.mbs.pos.services.tender.refundDueUISite">"/>
<SHUTTLE
class="TenderAuthorizationLaunchShuttle"
replacewith="com.mbs.pos.services.tender.MBSTenderAuthorizationLaunchShuttle"/>
</tour>
Modify the calling and nested tour scripts as necessary to adjust to the change.
Extending signals in the traditional object-oriented sense is not recommended. This is because signals are typically so small that extending an original signal class makes them overly complex.
The REPLACEWITH tag of the TourMap does not work for Signals. The tour script must be customized to refer to the package and filename of the new signal. Perform these steps:
Create a new signal class in the customer source tree. For example, create a replacement for IsAuthorizationRequiredSignal.java in the Tender service by creating a class file com\mbs\pos\services\tender\MBSIsAuthorizationRequiredSignal.java.
Customize the appropriate tour script.
Example 5-6 MBStender.xml: Tender tour script with customized signal
<SERVICECODE>
... non-signal declarations omitted...
<SIGNAL class="IsReturnTransactionSignal" />
<SIGNAL class="IsSaleTransactionSignal" />
<SIGNAL class="IsNotVoidTransactionSignal" />
<SIGNAL class="IsAuthNotRequiredSignal" />
<SIGNAL class="MBSIsAuthorizationRequiredSignal" package="com.mbs.pos.services.tender" />
<SIGNAL class="IsRemoveTenderSignal" />
<SIGNAL class="IsNoRemoveTenderSignal" />
<SIGNAL class="IsValidDriverLicenseSignal" />
<SIGNAL class="IsInvalidDriverLicenseSignal" />
... more declarations omitted...
</SERVICECODE>
... code omitted...
<ROAD name="AuthorizationRequested"
letter="Next"
destination="AuthorizationStation"
tape="ADVANCE"
record="OFF"
index="OFF">
<LIGHT signal="MBSIsAuthorizationRequiredSignal"/>
Since cargos do not mail letters, they may be extended or replaced. Cargo classes are typically part of a hierarchy of classes. Perform these steps:
Modify the cargo class by doing one of the following:
To extend the cargo, create a new class in the customer source tree that extends the cargo in the product source tree. Be sure to extend from the lowest-level subclass. Add the customer abbreviation to the beginning of the filename.
To replace the cargo, create a new cargo class in the customer source tree.
Edit the appropriate Tour Map for the locale, using the replacewith property in the <CARGO> tag to define the new package and filename for the cargo.
Modify the tour map and/or tour scripts and shuttles of the calling and nested tours to adapt to the cargo modifications. Be sure to address:
Classes in the same tour as the modified cargo
All tours for which this tour is a nested tour
All tours which are called by this tour
The UIManager and UITechnician classes are provided by Foundation. They are configurable through the Conduit Script and should not be modified directly. This section describes customization to the default UI configuration and individual screens.
The product file <source_directory>\applications\pos\src\oracle\retail\stores\pos\config\defaults\defaultuicfg.xml contains the building blocks for the UI (displays, templates and specs) and references to all tour-specific uicfg.xml files. If you change any UI script in the customer implementation, the defaultuicfg.xml file must be replaced. It also needs to be replaced if the displays, templates, and basic bean specs need to be replaced. Perform these steps to replace the file:
Copy the file defaultuicfg.xml to the pos\config\defaults directory in the customer source tree, and rename it (for example, to MBSdefaultuicfg.xml).
Modify the displays, templates, default screens, and specs as necessary to represent the customer's user interface.
Verify that the conduit script for the client tier has been customized and is located in the customer source tree.
Modify the client conduit script to include the new filename and package name for the MBSdefaultuicfg.xml file, in the configFilename property value in the UISubsystem section of the UITechnician tag.
Example 5-8 ClientConduit.xml: Conduit script modified to use custom UI configuration file
<TECHNICIAN
name="UITechnician"
class="UITechnician"
package="oracle.retail.stores.foundation.manager.gui" export="Y">
<CLASS
name="UISubsystem"
package="oracle.retail.stores.pos.ui"
class="POSJFCUISubsystem">
<CLASSPROPERTY
propname="configFilename"
propvalue="classpath://com/mbs/pos/config/defaults/MBSdefaultuicfg.xml"
proptype="STRING"/>
...additional class properties omitted...
</CLASS>
</TECHNICIAN>
A UI script changes if the overlays or unique bean specifications of one or more screens in a tour need to be modified. Perform these steps:
Create a new UI script in the customer source tree. For example, copy the tenderuicfg.xml file from the product source tree to the customer source tree and rename it MBStenderuicfg.xml.
Modify the MBSdefaultuicfg.xml file in the customer source tree to refer to the new filename and package for the UI script.
Example 5-9 MBSdefaultuicfg.xml: Customized Default UI Configuration File
... other include statements omitted... <INCLUDE filename="classpath://oracle/retail/stores/pos/services/sale/saleuicfg.xml"/> <INCLUDE filename="classpath://com/mbs/pos/services/tender/MBStenderuicfg.xml"/> <INCLUDE filename="classpath://oracle/retail/stores/pos/services/tender/capturecustomerinfo/capturecustomerinfouicfg.xml"/> <INCLUDE filename="classpath://com/extendyourstore/pos/services/inquiry/inquiryoptionsuicfg.xml"/> ... other include statements omitted...
The Point-of-Service product code provides generalized beans that are designed to be reused as-is, such as GlobalNavigationButtonBean.java for the global navigation button bar and DataInputBean.java for the work area of form layout screens. These classes are not intended to be extended for a specific implementation, though they may be extended if the general behavior or data must change in all cases.
The classes can be used for different screens within the application without changing to Java code by modifying parameter values and calling methods on the bean. Use the generalized beans whenever possible and avoid beans specialized for only one screen. However, bean and bean model classes in the product code that are specific to an individual screen, such as CheckEntryBean.java and CheckEntryBeanModel.java, may be customized. Perform these steps to modify a bean model:
Create a new bean model class.
Create a new class in the customer source tree, and add the customer abbreviation to the filename.
Copy tour files that need to reference the new bean model into the customer source tree. Modify them to create and manipulate data for the new bean model.
Perform these steps to modify the bean:
Create a new bean class.
Create a new class in the customer source tree, and add the customer abbreviation to the filename.
Modify the UI config scripts that reference the bean class in the customer source tree to refer to the new bean class filename and package.
Example 5-10 MBStenderuicfg.xml: Tender UI Configuration with Customized Bean Reference
<UICFG>
<BEAN
specName="TenderOptionsButtonSpec"
configuratorPackage="oracle.retail.stores.pos.ui"
configuratorClassName="POSBeanConfigurator"
beanPackage="com.mbs.pos.ui.beans"
beanClassName="MBSNavigationButtonBean">
<BUTTON
actionName="Cash"
enabled="true"
keyName="F2"
labelTag="Cash"/>
...other buttons omitted...
</BEAN>
...other UI objects omitted...
</UICFG>
This section covers customization of components other than the tour and the UI framework, including internationalization and localization changes as well as conduit scripts, PLAF, receipts, and reports.
For more information about Internationalization of Point-of-Service, see Internationalization.
|
Note: For internationalization, Point-of-Service can use multiple languages at any given time: either default language, user language or customer preferred language. Point-of-Service looks up resource bundles based on the selected language (store default language, user language or preferred customer language) plus the region from its default locale. If Point-of-Service cannot find this combination, it reverts back to the selected language only. |
For additional internationalization support of Oracle Retail Point-of-Service, please contact Oracle Retail Services.
The conduit scripts provided with Oracle Retail applications define a typical tier configuration and are usually replaced with customer conduit scripts for a given implementation. Conduit scripts include an XML file and a .bat and .sh file to execute the XML; both .bat and .sh versions of the batch file are provided to support Windows and Linux.
Perform these steps to set up customer conduit scripts:
Copy the conduit scripts (client and server) to the customer source tree.
Copy the XML and .bat and .sh files for each type of conduit script. Rename the scripts using the customer abbreviation (ClientConduit.xml becomes MBSClientConduit.xml).
Edit each XML file to include only the managers and technicians that should be loaded on the given tier.
Modify the class and package names for any managers, technicians and configuration scripts that have been customized.
MBSClientConduit.xml: Customized with New Data Manager
<MANAGER name="DataManager" class="MBSDataManager"
package="com.mbs.foundation.manager.data">
<PROPERTY propname="configScript"
propvalue="classpath://config/manager/PosDataManager.xml" />
</MANAGER>
Modify your development environment to pass in the new conduit XML file as a parameter to the TierLoader.
Edit the .bat and .sh files to pass the correct conduit XML files to the Java environment.
Point-of-Service implements a pluggable look-and-feel (PLAF) so that customers may modify the look of the application including screen colors and images. To modify the PLAF, follow these steps:
Create a new properties file that is a copy of one of the following files. Place the file in the com\mbs\pos\config directory in the customer source tree.
swanplaf.properties — yellow-and-purple, text-based LAF
imagePlaf.properties — blue and gold image-based LAF
|
Note: Each supported language has its own version of swanplaf.properties and imagePlaf.properties:
|
Update the conduit scripts in the customer source tree to specify the package and filename for the new LAF file in the UI Technician tag.
Have new UI beans call uiFactory.configureUIComponent(this, UI_PREFIX) in the initialize() method to set the look-and-feel.
Point-of-Service has a set of reports that print on the slip printer. The report document names are specified in the tour code.
To modify existing Point-of-Service reports and receipts, the report Java files can be extended. Perform these steps:
For each report or receipt, do one of the following:
To modify an existing report or receipt, copy existing BPT and change file name in BlueprintedDocumentManager.xml.
Create, modify or override data and methods as necessary to modify the report or receipt.
When it is necessary to have the Point-of-Service client print a new receipt, develop a blueprint (BPT) file for the receipt. However, it is extremely difficult to do this without a serialized instance of the object being printed prior, to aid in editing the blueprint. Since the BlueprintedDocumentManager has an option to serialize the parameter beans, you can use the Point-of-Service client to serialize what is printed for you. You will then have the serialized object file and then can use it to drag and drop method calls onto your new blueprint.
Ensure /pos/config/manager/BlueprintedDocumentManager.xml has the persistBeansAsDataObject value set to true.
Edit /pos/config/manager/BlueprintedDocumentManager.xml to contain a <RECEIPT> element for your new receipt.
Enter code in a Point-of-Service site to print your receipt. For example:
PrintableDocumentManagerIfc pdm = (PrintableDocumentManagerIfc)bus.getManager(PrintableDocumentManagerIfc.TYPE);
ReceiptParameterBeanIfc bean = getMyParameterBean()*;
bean.setDocumentType("MyNewReceipt");
pdm.printReceipt((SessionBusIfc)bus, bean);
|
Note: There are many ways to construct a PrintableDocumentParameterBeanIfc for printing. You can potentially use a method from PrintableDocumentManagerIfc or you can instantiate or use a subclass of PrintableDocumentParameterBean to create one of your own. |
Run the code and navigate through the Point-of-Service site.
A MyNewReceipt.ser file will appear in the /pos/receipts dir.
|
Caution: It is likely the Point-of-Service will fail here because the desired receipt bpt will not exist. |
In Eclipse, go to File > New > Other > type. Select Receipt.
You can also go to Oracle-Retail > Receipt Blueprint.
Name your file MyNewReceipt.bpt.
Attach MyNewReceipt.ser to the Receipt Data Object view.
|
Note: For more information, see the Oracle Retail Point-of-Service Receipt Builder Tool User Guide.This document is available through My Oracle Support. Access My Oracle Support at the following URL: Oracle Retail Point-of-Service Receipt Builder Tool User Guide (Doc ID: 1595733.1) |
As an alternative to using Point-of-Service to create the serialized file, it is possible to use the Object Inspector plugin to create an instance of your receipt parameter bean if it has a zero-arg constructor. This may be more convenient than running Point-of-Service, but the resulting serialized object does not contain any values to use when printing. You can use Object Inspector to execute simple set methods on your bean instance. Be sure your class implements PrintableDocumentParameterBeanIfc.
In Eclipse, go to File > New > Other > type and select Object.
You can also go to Java > Serialized Object.
Name your file MyNewReceipt.ser or a name that matches the name of the .bpt this file is used with.
Pick the class that implements PrintableDocumentParameterBeanIfc.
Click Finish.
Edit the value of this object as desired.
Open the Receipt Builder editor and attach your new file.
|
Note: For more information, see the Oracle Retail Point-of-Service Receipt Builder Tool User Guide.This document is available through My Oracle Support. Access My Oracle Support at the following URL: Oracle Retail Point-of-Service Receipt Builder Tool User Guide (Doc ID: 1595733.1) |
If you are using the sample class provided in Step 0 to create a receipt, the following steps create a serialized file and blueprint with which to print. In Eclipse, do the following to create a data object and blueprint using the Person.java downloaded from the link in Step 0
If no Java Project exists, create one. Go to File > New > Java Project.
Name your project , such as receiptbuilder. The default settings will be fine.
Click Finish.
Access the project and select the src folder.
Go to File > New > Package and create a package named com.demo.
Right-click on the com.demo package and select Properties.
Using Windows Explorer, go to the com.demo package directory and Paste Person.java into the package.
Right-click on the com.demo package and select Refresh to make Person.java appear in Eclipse.
Right-click the com.demo package and go to New > Folder and create a folder called objects.
Right-click on the objects folder and go to New > Other > Java > Serialized Object.
Click Next.
Click Browse.
Type Person. Click OK to select com.demo.Person class.
Click Finish.
In a new editor window, go to com.demo.Person > Person > init(). This will provide some values.
Go to setBirthDate(Date). Specify a date and click OK.
Go to getBirthDate() to see your value.
Click Save.
Right-click on the project and go to New > Folder and create a folder called receipts.
Right-click on receipts folder and go to New > Other... > Oracle-Retail > Receipt Blueprint.
Click Next.
Click Finish.
Attach the serialized Person.java to the Receipt Data Object view. Do this by clicking Attach RDO button or drop-down menu option.
Type object.ser. Select OK to attach the object.
Rename the element with the word text in it to Name:
Do this by double-clicking the element and editing directly, or select the element and in the Properties view, edit th on the General tab.
Drag Person.getName() from the RDO view to the right of Name:.
Go to com.demo.Person > Person > getName(). Select this item.
Drag this tree item to the right of the Name: element and drop it.
Click Print. The output should look like this:
------------------------------------------ Blueprint@12291679 ------------------------------------------ Name: John Smith
Click Save.
Continue to edit the receipt with the palette on the right side of the editor.
Create a receipt with output that looks like the following:
------------------------------------------
Blueprint@12291679
------------------------------------------
(8/13/08) 11:35 AM
Id: 1234 Name: John Smith
Height: 0.0
Age: Voided 12,346
Sex: male
Salary: 80,000.00
Nick name: "Johnny"
Birth Date: Jul 18, 2008
Spouse: Sara Smith
________________________________________
Relatives
----------------------------------------
Name: Joe Smith
Age: 84E0
Name: Sally Smith
Name: Sandy Smith
This section addresses customization of files in the domain package. The domain package can be found in the \OracleRetailStore\domain directory in your source control system.
The Retail Domain provides a retail-specific implementation of business objects. These objects are easily extended to meet customer's requirements.
If any Retail Domain Objects (RDOs) are added or extended, the DomainObject Factory must be extended. This needs to be done only one time for the application. The extended class must include getXinstance() methods for all new and extended RDOs, where X is the name of the RDO. Perform these steps:
Create a new Java class that extends DomainObjectFactory.java. It should be named with the customer abbreviation in the filename MBSDomainObjectFactory.java and be located in the customer source tree.
Copy the domain.properties file to the domain\config directory of the customer source tree. Modify the setting for the DomainObjectFactory to refer to the new package and class name created in the previous step.
DomainObjectFactory=com.acmebrick.domain.factory.MBSDomainObjectFactory;
Add getXInstance() methods as necessary for new Retail Domain Objects.
Perform these steps to create or extend an RDO:
Complete one of the following steps:
To create a new RDO, create a Java class in the customer source tree in the appropriate subdirectory of domain\src\com\mbs\domain. Extend an appropriate superclass from the product code. At a minimum, the new class must extend EYSDomainIfc.java.
To modify an existing RDO, create a Java class in the customer source tree that extends an RDO in the product code.
Include the customer abbreviation in the filename; for example, you might name your class file MBSCustomer.java.
Add data attributes and methods required by the customer-specific functionality.
Create setCloneAttributes(), equals() and toString() methods to address the new data attributes and then reference the corresponding superclass method.
Complete one of the following steps:
For a new RDO, add a new getXInstance() method to MBSDomainObjectFactory.java for the new RDO.
For an extended RDO, override the existing getXInstance() method in MBSDomainObjectFactory.java to return an object of the new class type.
Access the new RDO data and methods from tours located in the customer source tree. If product tours need to access the new RDO data and methods, the tours must be modified.
If the RDO data is represented on a screen, modify the UI script, bean and bean model classes to reflect the change.
If the RDO is saved to the database, modify the data operation to save the new data attributes.
This section details how to extend database behavior through changes to the data operations. The architecture of the Data Technician simplifies this somewhat, because changes to data operations can be implemented without changes to the Point-of-Service application code.
The Data Manager and Data Technician Scripts, PosDataManager.xml and DefaultDataTechnician.xml, are routinely customized when transactions, data actions, and data operations are customized. See the next section for details.
When a new or modified RDO contains data that need to be saved to the database, a data operation class must be created or extended. A Data Action must be modified if a unit of database work is changed.
Create class files.
Create new class files for each new or modified item in the customer source tree. If an item extends a product class, add the customer abbreviation to the filename.
If a customized version of PosDataManager.xml does not already exist, copy it to the customer source tree and give it a new name, such as MBSPosDataManager.xml.
For customized transactions with new filenames, modify the transaction name.
If a customized version of DefaultDataTechnician.xml does not already exist, copy it to the customer source tree and give it a new name, such as MBSDefaultDataTechnician.xml.
Edit the customized MBSDefaultDataTechnician.xml file, updating package and class names for data actions and data operations that have been modified.
Modify the conduit scripts to reference the new package and/or filename of the technician script.
Data transactions are the valet classes that carry requests from the client to the server. A data transaction factory implements the factory pattern for data transaction classes. The application code asks the factory for a transaction object and the factory determines which Java class is used to create the object. To create or extend a data transaction class, follow these steps:
Create new or modified data transactions.
Create a Java class in the customer source tree and prepend the customer abbreviation to the filename. If you are modifying an existing transaction, have the class extend the transaction class in the product code, and overwrite the methods you are modifying.
Copy POSDataManager.xml to the customer source tree.
For customized transactions with new filenames, modify the transaction name.
Copy DefaultDataTechnician.xml to the customer source tree.
Modify package and class names for data actions and data operations that have been modified.
If not already done, modify the conduit scripts to reference the new package and/or filename of the technician script.
Extend DataTransactionKeys.java as MBSDataTransactionKeys.java in the customer source tree to add or modify the static final String for each transaction (the file serves as a list of string constants).
Update domain.properties in the customer source tree to add or modify the name/value pairs for each transaction.
Example 5-14 domain.properties: Sample Modified and New Data Transactions
# Registry of DataTransactionIfc implementations
# (try to keep in alphabetical order)
#
data.transaction.ADVANCED_PRICING_DATA_TRANSACTION=oracle.retail.stores.domain.arts.AdvancedPricingDataTransaction
...code omitted here...
data.transaction.REGISTER_STATUS_TRANSACTION=com.MBS.domain.data.transactions.RegisterStatusTransaction
data.transaction.REGISTRY_DATA_TRANSACTION=oracle.retail.stores.domain.arts.RegistryDataTransaction
data.transaction.STORE_LOOKUP_DATA_TRANSACTION=com.MBS.domain.data.transactions.StoreLookupDataTransaction
MBSdata.transaction.DATA_MAINTENANCE_TRANSACTION=com.MBS.domain.data.transactions.DataMaintenanceTransaction
MBSdata.transaction.PLU_RETURN_TRANSACTION=com.MBS.domain.data.transactions.ReturnPluTransaction
