Mobile Applications Customization

Download Mobile Applications Customization

Post on 22-Nov-2014

883 views

Category:

Documents

8 download

Embed Size (px)

TRANSCRIPT

<p>Customization of Oracle Mobile Supply Chain Applications and Oracle Warehouse Management SystemAn Oracle White Paper September 2002</p> <p>Customization of MSCA/WMS</p> <p>OVERVIEW</p> <p>Oracle Mobile Supply Chain Applications (MSCA) and Oracle Warehouse Management Systems (WMS) are both comprehensive supply chain solutions for small and large businesses alike. However, given their broad application, not all businesses may want to use these products exactly as shipped. Given that the requirement for customization is possible, the MSCA and WMS products have been architected with a careful use of object hierarchy and an extensible, modular design capable of being customized. In most cases however, customization of Oracle mobile pages shall require basic knowledge of data flow through the customized transactions and an acute knowledge of objectoriented design. Using the tools and tricks provided in this section, either an application developer or a consultant could customize mobile pages for a particular look/feel, or business logic specific to the companys needs.</p> <p>Any level of customization, even one using the techniques described within this White Paper that act to reduce ongoing maintenance issues, should be carefully evaluated and cost justified. Just because it looks easy does not mean it is a good idea. Although this document attempts to elucidate a methodology to best customize MSCA and WMS code, it is highly recommended that customers modify and add programmatic code as a last resort. Maintenance, support, liability during patching, duplicated effort, and inconsistency in execution are all elevated through customizations, and consequently may delay a customers implementation. Therefore it is always advisable to find non-programatic workarounds if possible.</p> <p>This document outlines best practices for customization of MSCA and WMS mobile transactions, and delves into the technical details specific to Oracle MSCA and WMS products. The most appropriate readers are implementation consultants attempting to customize the mobile forms specific to a customers needs. This document will attempt to elucidate all technical terms and minimize prior knowledge of specific Java coding standards. However, prior basic knowledge of Oracle applications is assumed.</p> <p>1</p> <p>The Transaction StructureTerminology</p> <p>Java Bean - A Java Bean is an object of a particular class type, with set variables contained in it and access methods for those variables. Mobile Transaction A full transaction, potentially consisting of one or more mobile pages.</p> <p>Mobile Application Beans</p> <p>A mobile application, as defined by MSCA and WMS products, is built using the following Java Beans: 1) A MenuItemBean is needed to attach the mobile application to the Oracle Desktop ERP. It contains no page layout information on its own, but is a necessary conduit to connect the Desktop ERP to mobile transactions. At the leaf node of the FND menu structure lays an FND Form Function that points to the MenuItemBean. The MenuItemBean in itself points to the first page in the application, which is represented by a PageBean. 2) A PageBean represents the unit of display (ie. a single screen on a mobile client). To define a new page, the developer must extend the PageBean, and make a new page bean class. Within this new class, the developer must use the new PageBean's constructor to instantiate FieldBeans (graphical components), and add them to the page. 3) The FieldBean is a super class for all data collection/display graphical components that the developer can use in their pages. When the mobile server loads a new page, it calls the user defined PageBean's constructor, which in turn creates all of the graphical components on that page. Examples of FieldBeans are TextFieldBean, ButtonFieldBean, LOVFieldBean, MultiListFieldBean, ListFieldBean, HeadingFieldBean, SeparatorFieldBean. Because each of these beans is written in Java, each one can consequently be extended with additional functionality. Customers should have a strong grasp of what a bean is, how the three types of mobile beans relate to each other, and finally how they connect to Oracle Applications Desktop ERP. When constructing a page, it is important to note that ERP forms connects to a MenuItemBean, which in turn links to a PageBean, which in turn contains many FieldBeans, as shown below.</p> <p>2</p> <p>Menu</p> <p>M MenuItemBeanImplements MWAAppListener</p> <p>P PageBeanimplements MWAPageListener</p> <p>F FieldListenerimplements MWAFieldListener</p> <p>Mobile Application Event Logic</p> <p>An application's runtime logic is specified through the mobile applications event model, a set of interfaces that provide an infrastructure for handling events in an organized and modularized fashion. Based on the existing Java Listener model, a listener can be added to any field, page, or application of your mobile transaction. The following is a list of listeners available: FieldEntered this is called when a particular field is entered. For example, prior to entering a particular field, there may be a need to reinitialize some variables. FieldExited this is called when a particular field is exited. The most common of the listeners, this is used for validation of user input. PageEntered called when the page is entered, this can be used to initialize values on the page. PageExited called when the page is exited, this can perform page level validation logic. AppEntered called when the entire transaction is entered, this can be used to initialize transaction level variables. AppExited called when the entire application is exit, an example use can be to close resources. SpecialKeyPressed this is called when the user presses any special character, such as a Control character. Pressing CTRL-G to generate LPNs or Lots is one example of when this gets called.</p> <p>Listeners exist to perform validation, hide show fields, reinitialize variables, etc. Given this transaction structure, please refer to the Appendix (A.1-A.3) for an example of a full transaction. All MSCA and WMS transactions follow nearly the same structure. Therefore, understanding one transaction should lead to faster understanding of all.</p> <p>3</p> <p>ADDITIONS IN FUNCTIONALITY OR APPEARANCE</p> <p>The simplest customization is the adding of functionality to a transaction. This may be in the form of adding extra fields, such as an extra button, or adding extra validation when a particular field is exited, or perhaps defaulting the value of a field based on a particular value entered in a previous field. However, this does not entail making modifications to the existing structure and flow the transaction. Because customization, as the definition of the word, is a very individual process, we shall examine the most frequent cases of customization and deal with each one individually. In the process, you should gain a logical understanding of the object-oriented design practice of inheritance that will guide you in building more specific and custom requirements.</p> <p>Examples 1) Add application level initialization or destruction 2) Add page level initialization or destruction 3) Adding a field and event handling itExample 1)</p> <p>In order to add application level logic, you must extend the MenuItemBean and override the existing appEntered and appExited methods. Be certain to include a call to super() when overriding these methods.</p> <p>Menu</p> <p>M MenuItemBeanImplements MWAAppListener</p> <p>P PageBeanimplements MWAPageListener</p> <p>F FieldListenerimplements MWAFieldListener</p> <p>M MenuItemBeanoverrides appEntered aand appExited</p> <p>4</p> <p>From the above diagram, you can see that M extends M and overrides the necessary methods. Now, every time the user navigates to the menu, the new MenuItemBean is launched instead of the original one. Suppose your company requires a specific global variable be called upon start of a transaction. Here is example code of M to accomplish this task.</p> <p>public class M extends M { public void appEntered(MWAEvent e) throws AbortHandlerException, DefaultOnlyHandlerException, InterruptedHandlerException { super(e); //initialize my companys global variable here } }</p> <p>Now, each time this transaction is entered, the above added logic shall be executed.Example 2)</p> <p>Adding page level validation is almost identical to example 1 above, however it is now P that must be extended and the methods pageEntered and pageExited that can be overridden.</p> <p>Suppose your company requires the user id be displayed on the status bar every time the page is loaded. Here is example code of P to accomplish this task.</p> <p>Menu</p> <p>M MenuItemBeanImplements MWAAppListener</p> <p>P PageBeanimplements MWAPageListener</p> <p>F FieldListenerimplements MWAFieldListener</p> <p>M MenuItemBeanoverrides appEntered aand appExited</p> <p>P PageBeanoverrides pageEntered and pageExited methods</p> <p>5</p> <p>public class P extends P { public void pageEntered(MWAEvent e) throws AbortHandlerException, DefaultOnlyHandlerException, InterruptedHandlerException { super(e); e.getSession().setStatusMessage(/*Employee User Id*/); } }</p> <p>Now, each time this page is entered, the above added logic shall be executed.</p> <p>Example 3)</p> <p>Adding and extra field on a page is similar to case 2. The developer is required to first extend P, then in the constructor of P', first call super(), and then instantiate and add the new field. If a new Cancel Button were to be added to P, This can be implemented as follows:</p> <p>public class P extends P { ButtonFieldBean mCancelBtn; CancelButtonFHandler cancelHandler = new CancelButtonFieldHandler(); public void P'(Session p_session) { super(p_session); //if the parent constructor takes a session, else use the default constructor mCancelBrn = new ButtonFieldBean(); mCancelBtn.setName("CANCEL"); mCancelBtn.setPrompt("Cancel"); mCancelBtn.addListener(cancelHandler); // now add the field at the end of the page this.addFieldBean(mCancelBtn); } }</p> <p>We must now implement the handler that cancels the transaction:public class CancelButtonFHandler implements MWAFieldListener { public void fieldEntered(MWAEvent e) throws AbortHandlerException, DefaultOnlyHandlerException, InterruptedHandlerException { } public void fieldEntered(MWAEvent e) throws AbortHandlerException, DefaultOnlyHandlerException, InterruptedHandlerException { e.getSession().setNextPageName(MWALib.NEXT_PAGE_NAME_END_OF_TRANSACTION ); } }</p> <p>Development</p> <p>Choice of development method for customized Java and PL/SQL code is left to the application developers discretion. There is no certified or best development method for creating custom code. Therefore, it is left to the programmer. Possible methods range from a full-fledged Integrated Development Envirnoment, such as Oracle JDeveloper, to simple editors such as VI or EMACS.</p> <p>6</p> <p>Since Oracle JAVA code is not shipped, the Oracle MSCA/WMS team shall provide the Javadocs for all transactions. Therefore, all the APIs, variable names, and private information will be available to the customization developer. To obtain the Javadocs, please download them from the same location as this file.</p> <p>Deployment</p> <p>All Oracle Java files are located in the $AU_TOP/java/apps.zip file. Custom code can be placed anywhere, as long as its location is in your CLASSPATH. Be certain that you recompile your custom code after every modification, to either apps.zip or the custom code. Additionally, to verify the location of where class files are being picked up by the Mobile Applications Server, it is possible to modify the mwactl.sh file to run java in verbose mode. This will provide a runtime explanation of whether code is being picked from the apps.zip file or the custom code location. For a detailed explanation on the Mobile Applications Server, please refer to the MWA Administration and User guide.</p> <p>Release Management</p> <p>The Oracle patching process may in the future overwrite any Java or PL/SQL file shipped. Therefore, any strategy for customization must include a method to overcome the headache of re-implementing code change after patches. The strategy mentioned in this document uses object oriented design to never modify original files, and therefore any modification to the original files through patching does not erase custom code. However, it is possible that the execution path of the original files may change, and hence the execution of the custom code may be effected. In this situation it will be necessary to re-evaluate and reprogram the customization. Always remember that customization is a last resort, as there is no fail-safe method of ensuring it need not be rewritten. From a technical standpoint, please remember to recompile all custom code each time a new patch is applied. This will be necessary to ensure proper execution of custom code.</p> <p>Support</p> <p>Oracle Corporation does not support custom code. Given the innumerable number of customer customizations, it is not possible for Oracle Support Services to debug and fix infinitely many branches of code. Therefore, the person customizing code should be a fairly adroit programmer and capable of development, support, update, and enhancements to the software.</p> <p>7</p> <p>Form Function</p> <p>When creating custom classes it is necessary to modify the form functions under the Application Developer responsibility to point to the custom Function instead of the existing one. This can be done by logging into the application developer responsibility and querying the form functions that currently exist.</p> <p>Query up the existing functions that suit your menu option and copy the data to a new form function. The WebHTML tab must be modified to point to the new Custom function pages. Also make certain that your new form function is pointed to by some menu structure.</p> <p>BEST PRACTICES CHECKLIST</p> <p>1) Dont perform the customization if it can be avoided. 2) Modification of our Java classes and PL/SQL packages directly should be the last resort. Any change made to existing classes and packages may be overwritten every time Oracle releases a new patch. In Java it is always best to extend existing classes and modify functionality. In PL/SQL, it is best to create new packages. 3) Addition of logic and layout is far easier to do versus removal or logic and layout. Therefore, properly evaluate your business needs, see if a workaround exists, and if possible, add logic to obtain the desired result.</p> <p>Case Studies</p> <p>This section examines specific business needs that are not addressed fully by the Oracle products, and may be required for some businesses. Each case is an example of a real business requirement that has become salient during the Oracle WMS Early Adopter program.</p> <p>8</p> <p>Case 1: Removal of the Oracle List of Values (LOV)A large drug manufacturer XYZ recently elicited the need to remove LOVs from mobile transactions and require that every scan be individually validated against the database. This would ensure that if an improper scan occurred, there would no method for the user to select another item from the list...</p>