Customizing RedPrairie RF Forms (Java Based)

Customizing RedPrairie RF Forms

Java Based MTF Forms

Overview

As of version 2009, RedPrairie uses Java to provide RF forms.  The underlying engine is called "MTF" (Mobile Terminal Framework).  These applications are VT based applications that may be accessed via telnet or ssh protocols.

Deployment Architecture

1. A MOCA task exists for each vendor and warehouse combination.  The task listens on a specific port and for a specific protocol (i.e. telnet or ssh).  One task serves a single vendor (e.g. LXE, Intermac, or Default) and a specific warehouse
2. The task also points to a MOCA connection URL.
3. Clients connect to the specific task using ssh or telnet protocol
4. If the vendor setup is defined correctly, the form will go directly to the login prompt and device identifier (devcod) will be determined based on RF Vendor setup.  If not defined (e.g. DEFAULT vendor), then system will prompt for a device.  This device is determined based on setup in "RF Terminal Maintenance"

Software Layout

"MTF" is a separate software component similar to MOCA, MCS, SAL, DCS, etc. and exists at the same directory level.  This component is the underlying engine that runs MTF.

The actual forms are provided by the component that uses it, which by default is "DCS" and when we have some customized forms then also "LES".

Within each component that uses MTF, the objects exist in mtfclient/ sub-folder.  The whole solution is compiled using "ant" which works off a file called "build.xml" in $LESDIR.

Within LES folder, the customized objects will exist in "mtfclient\src\java\com\redprairie\les" sub-folder and in that folder you can have one or two sub-folders that represents the customized objects:

• formlogic 
• mtfutil

formlogic folder has the forms and mtfutil is needed for common classes. 

RF Form Invocation Mechanism

When MTF calls a form, it uses the "createFormLogic" method, e.g:

As you can see we are calling it by a name and not invoking the java class directly.  This setup is in rf_frm_mst table:

The custom entries have cust_lvl of 10 and the frm_cls points to the actual class path.  You can see how this mechanism allows for overriding standard forms as well:

Creating a new RF Form

So creating a new RF form is quite straight forward, given that you know the underlying mechanism for creating the required java objects.  You will put the new form in the formlogic folder and compile the code.  You will put that in the desired menu and give the permissions to the appropriate roles.  When MTF needs to invoke the form, it will use the rf_frm_mst data to find the highest customization level and instantiate that class.

Overriding Standard Forms

This is the main reason for this blog.  I have seen far too many cases where the override is done by straight copy/paste of standard code and then modifying a few lines of code for the enhancement.  Anyone who understands basic OOP principles will get a heart burn by reading this but unfortunately far too much code exists like that.  Just look in your installation in this folder and see code like "PickupA.java", "DepositA.java", etc. and if that code is based on straight copy/paste of standard code - you are a victim of this practice.  This basically implies that in case of a version upgrade, java is not going to help - you will have to retrofit these forms and somehow obtain the new source code.

Overriding Standard Forms - The Right Way

There is no advantage of using Java in MTF if the language is not utilized fully.  Sure, java syntax is more mature than old RF forms but if you see the code there is really one to one correspondence - actually RedPrairie provides a converter that can take the old "rdt" files and convert them to "java" files.

The advantage is only if "java" is utilized fully.  As always, the RedPrairie architecture is not at fault.  Just like MOCA, MTF framework supports the "right way".

Lets say all you want to do is that when "DepositA" is invoked, it should do something different in "formEntry" than what it does right now.  You can see what it does right now by looking at MTF and MOCA traces.

So the right approach will be to do just that and nothing more:

• Create your class as an extension of the base form

• Then override the method that you did not like

Here "formEntry" and "formExit" represent overridden methods that can have any code that you want.

• And then add an entry to "rf_frm_mst" to call "UsrDepostA" when DEPOSIT_A is called.

Overriding Methods In CWmdMtfUtil

This class is provided by DCS component and it contains several utility methods that are called by various forms.  For example when directed work form is invoked, it calls "getWork" method from this class.  

This class does not have a simple mechanism like forms, i.e. there is no table where we can put our class path so that RedPrairie invokes that instead of this class so this is a bit tricky!

When a form needs to call a method from this, it will have code like:

So what we want to do is put our extended class in this session map.  If we can do that, the concepts described above would work.  So our approach will be:

• Extend the CWMDMtfUtil class

• Then override what you did not like

• And then find a suitable point where we can replace the session map with our object.  A reasonable location may be the undirected menu.  Undirected menu will be overridden using technique described above.

And thats it - now when we go to the undirected menu, after displaying it, it will replace this session variable and from that point on our override method will be invoked.

Conclusion

Cut/paste approach is often employed when modifying the Redprairie code.  This problem exists at all levels - for example the "libsrc\varint" folder sometimes contains large C files with names like "trnAlloc.c" - that is a huge concern because that is core of RedPrairie and if that is customized say good bye to easy upgrades. 

Same issue manifests at RDT level and GUI level.  Even though RedPrairie architecture is almost perfect to support extensions, implementations are often sub-par.  Customers should closely watch what objects are part of the rollouts they receive and if standard objects are being modified a red flag should be raised right there.

We have been able to successfully implement complicated enhancements without touching the underlying standard code.  There could be situations where the only solution is to modify the base code.  In those situations it is better for the customer to give up on the enhancement or come up with some compromise where the base code does not need to be touched.  

Carrier Pro Number Generation in RedPrairie

Overview

In recent weeks, multiple people have asked me about generating check digits for carrier BOL or Pro Numbers.  Some customers were told that creating such logic will be a mod - so I wanted to document some of the standard features that are available in RedPrairie.  The information should be relevant to at-least 2009+ versions of RedPrairie DCS - maybe even earlier.

Carrier Pro Number Maintenance

RedPrairie provides a application called "Carrier Pro Number Maintenance" to define the pro number algorithms for the carriers.

This screen has a dropdown that shows the list of available algorithms.  These algorithms are defined in code master as column name of chk_dgt_mthd.

Currently several methods are available, for example:

Check digit routine for Yellow Transportation

• Check digit routine for US Freightways
• Check digit routine for Southeastern Freightlines
• Check digit routine for Roadway Express
• Check digit routine for Road Runner Freight Systems
• Check digit routine for Pitt Ohio Express Inc
• Check digit routine for Overnite Trucking
• Check digit routine for Nations Way Transport
• Check digit routine for Estes Express
• Check digit routine for Con-way Central
• Check digit routine for Circle Delivery Inc
• Check digit routine for Arkansas Best Freightways
• Check digit routine for American Freightways

Under the Hood

These components are under %SALDIR%\src\cmdsrc\salpronumber.  Policy SAL-SHIPPING/PRO-NUMBER/COMMAND-MAPPING maps the pro number codes (as defined in code master) to MOCA commands.

The commands expect two arguments:

• prefix
• baseString

To test any of these algorithms, you can call them with these two parameters.  It will return the check digit in a column called "checkDigit", e.g.

calculate abf mod ten digit

where prefix = '123' and baseString = '457'

will return "9" as checkDigit

The pronumbers are generated through MOCA Command "generate next carrier pro number" which in turn looks at the car_pro_num and related tables to get the next number, generate its check digit, and return the new pro number.  It also updates the internal tables so that the next pronumber can be generated with the next number in the sequence.

Creating your own check-digit component

First see if one of the existing ones would work.  Unfortunately you will not be able to see the source code since these are implemented in "C" or "Java" - but command documentation may still provide you enough details.  If one of the existing ones work, then you are done!  

Otherwise to create a new one, follow the same convention with respect to input and output parameters for the command.  Create your command and add that to the code master and the policy.  Name your data with "usr" or "uc" prefix to make sure it is segregated from standard product offerings.

Will my RedPrairie system handle the load?

Overview

Stress Testing the production system is an important part of go-live readiness for new installs and upgrades. You want to be able to simulate the stress on the system so that the system can be tuned properly before going live.

Oracular Stress Tester

Oracular has created a solution for RedPrairie that simulates load for the system by creating virtual pickers and receivers. These agents run from a client machine and run the MOCA commands that simulate the user actions. The solution spaces out the system interactions randomly to simulate real-world environment.

Concepts

Profile

You can create several profiles for the stress test. When we run the solution, we run a specific profile.

Tasks and Users

We have two types of clients - tasks and users. Tasks are used to simulate automated processes that constantly run as a client to create work for the users. These are similar to RedPrairie tasks and jobs. Users correspond to actual users. We create users on the fly based on a template user id.

Metadata

The meta-data for the runs is stored in policies. The meta-data is very abstract so it does not take a long time to setup:
• Modify the template picking and receiving commands based on specific business processes
• Modify the commands that create work for the pickers and receivers
• Define a template user id
• Define number of users for each job code, e.g. how many pickers, and receivers, etc.
• Run it
• Analyze the results. Basically you are watching for the difference between min/max times. A high variance over a long period implies that stress is not being managed very well

Use Case

• From Oracular MOCA Client, launch stress Tester (Note that the free version of Oracular MOCA Client is not licensed for this module)
First open a tab for the connection, then launch the external application

.


• You can maintain the meta-data from here or by going to the respective policies
General Setup 


Maintain users 


Maintain tasks



• Go to the "Run" tab and press Run
This launches the stress tester. Each dot in the middle section represents a type of users. When it is doing something, it turns green. The grids are showing what it is doing at a given time.



• Press "Run" again to stop the test.
• Go to the "Report" Tab to see the results.
The results are also kept in a few database tables.

Conclusion

As you can see from the results, the information can be very useful.  A large difference between min and max may imply that the system faces contention as the number of users grow.  This may offer opportunity to tune the system before it is placed in production.

If you need more information about this solution, contact me at saad.ahmad@oracular.com

RedPrairie RF - Meet Android

Overview

RedPrairie provides an RF solution which typically runs on the handheld or vehicle mount devices made by vendors like intermac, LXE, etc.  At its core the solution is a VT emulation that is served over telnet protocol.  Oracular has made a solution that provides a friendly emulator for serving RedPrairie RF forms on an Android Phone.  You can download our app from the Android App Store 

Here are some features that may interest you:

• Integrated Scanner.  Download "Barcode Scanner" by ZXing.  Our app will utilize this app to provide barcode scanning capability
• Easy access to function keys.  Swipe from the left to get a list of function keys
• Supports pointing on menu options
• Two keyboards; swipe from below to get a normal keyboard or swipe from above downwards to get a numeric keyboard
• Integrated with RedPrairie device recognition.  When you sign on, the first screen the software will automatically key in the device identifier

For an advanced version of this solution that can be used in all environments including warehouse floor see our advanced version.

Typical Use Case

This app should be handy for IT support staff or the supervisory staff within a warehouse.  They no longer have to carry their laptop around or ask someone else for their RF device.  They can simply use their phone to launch any RF application.  The integrated barcode scanner would come in handy as well.

Setup

In order to use this solution, you should setup a dedicated task on the server.  The only requirement is that the task has "-G" option.  For example:

Then setup a device and RF Terminal Master entry.  If this setup is missing, then the android device will prompt for the terminal id.

In RF Terminal Maintenance, setup the device as a narrow device.  This app is optimized for 20*16 display.

Now when you connect from the Android device, you can define that as the terminal id (e.g. SAHMAD-PHONE).  The resulting connection to the server will be with that devcod.

Using the App

Before installing this app, install the "Barcode Scanner" app by ZXing.  That will allow you to use the integrated camera as a scanner.  Our software will be installed as "Oracular RedPrairie RF Emulator"

When you enter the app, you can press "Edit Servers" to define the servers that you want to connect to:

• Name: A name for this session
• Server: Host:Port for the MTF server
• Terminal Id:  This is the device name that you defined above.  When terminal id screen shows up, the app would type in this value
• username and password are optional

In the next screens, you can use certain gestures as needed, for example to get the function keys swipe from the left:

You can then press any key.  To get the integrated barcode scanner, swipe from the right:

The barcode scanner would recognize a barcode and key in the value on the field where it was invoked.  You can swipe from below to get the normal keyboard:

And to get a numeric keypad, you can swipe from above:

You can hit the back key to mimic "F1" behavior.  When on the menu, you can either enter the menu option or just tap on the menu option that you want to go into.

Download the app and use it.  Let us know what you think about it or if you see any issues.  You can contact me directly or send an email to android-rpemul@oracular.com.