When you implement an SAP system for a warehouse you have to keep in mind the needs of end users – workers moving around the warehouse taking products out of bins or putting products in bins. If these workers use the SAP system to perform day-to-day warehouse operations, they need mobile radio frequency (RF) devices that they can carry in their hands. Therefore, it is important to know how to develop SAP transactions that you can run on handheld RF devices.

When I was given the responsibility of implementing SAP for a warehouse operation, I didn’t find one document that told me all that I needed to know for the technical development of RF transactions for a warehouse. I hope that this article closes that gap and provides all that a technical developer or technical project manager needs to know before getting started with a warehouse management SAP project.

Project Team

An RF transaction project always includes three kinds of team members: a business process expert, an SAP functional expert, and an SAP technical developer. . The business process expert works on defining the requirements and needs of end users working in the warehouse. The SAP functional expert takes the business requirement and defines how it will be satisfied in the SAP system. It is important that the SAP functional expert have knowledge of the materials management (MM) and warehouse management (WM) SAP modules. The functional expert is responsible for making the necessary configuration in the SAP system to run RF transactions, to identify any standard SAP RF transaction that can be used to meet the requirement, and to figure out when a custom RF transaction needs to be developed. The SAP technical developer should have experience with developing ABAP Dynpro transactions and knowledge of ITSMobile. The developer needs to be able to create an Internet Communication Framework (ICF) service and create HTML templates.

RF Transaction: Approach for Requirement Analysis and Development

In the following sections I walk you through the steps for gathering user requirements for RF transactions, looking at what SAP RF transactions are available, and then developing custom RF transactions, if necessary.

Gathering Requirements for RF Transactions

To understand users’ requirements for RF transactions, you need to take a tour of their warehouse and ask them to explain all the operations performed there during any given day. All RF project team members should participate in this tour. The operations in a warehouse may include moving products from one bin to another, receiving goods from the production line or suppliers and putting them in storage bins, picking goods from storage bins and packing and loading them in a truck so that they can be shipped to customers, and so on. While taking this tour remember to ask a variety of questions to ensure a good understanding of their business processes. Pay particular attention to the operations that must be performed using an RF device. Keep in mind that some operations may be performed from the desktop using either an RF transaction or a standard SAP transaction.

Analyze Standard SAP RF Transactions

Once you have gathered users’ requirements for RF transactions, you need to take a look at the standard RF transactions that SAP offers. It’s possible that you may be able to use them as is.

As a follower of SAP best practices I always advise my clients to fully leverage standard SAP transactions and processes. Therefore, in this context it makes sense to be familiar with the list of standard SAP RF transactions. Table 1 lists some of the standard RF transactions offered by SAP in SAP ERP Central Component (ECC). At a minimum you need to use transaction codes LM00 and LM01. Transaction code LM00 is for the RF logon screen and transaction code  LM01 is for a dynamic RF transaction menu. You have to use them even if you decide not to use any other SAP RF transactions.

Table 1

List of SAP-provided RF transactions

Logon Transaction LM00

Transaction code LM00 is the starting point for a user who is ready to log on to an RF device. Figure 1 shows the transaction screen. One of the most important fields here is the Screen format field. RF devices used in a warehouse are available primarily with two screen sizes. Handheld RF devices have smaller screens with an 8x40 screen format, meaning the SAP GUI transaction screen has eight rows and 40 columns. The other RF devices have bigger screens and cannot be carried by hand; rather, they are mounted on forklifts. For these RF devices you use a 16x20 screen format, meaning a screen with 16 rows and 20 columns.

Figure 1

RF logon transaction code LM00

RF Main Menu Transaction Code LM01

RF transaction code LM01 is for an RF dynamic menu (Figure 2). You set up a dynamic menu using Customizing IMG menu path Logistics execution > Mobile data entry > Define menu management. You link the RF transaction codes to the main menu transaction code LM01. By default, standard SAP RF transactions are linked to the main menu transaction code LM01. You can take out what you don’t need and add your own RF transaction if you have developed one. This configuration setting is performed by MM or WM functional experts.

Figure 2

RF main menu transaction code LM01

Using Custom RF Transaction Codes

If a business requirement can’t be met with a standard RF transaction, you have two options available. You can enhance an SAP RF transaction or you can develop a custom transaction.

The first option is to change the standard SAP transaction using a user exit. Table 2 lists some of the available user exits to enhance the functionality. All these RF screen enhancement names start with MWMRF*.

Table 2

Sampling of available user exits

The second option is to develop a custom Z* RF transaction. You develop custom Z* RF transactions just like any other Web Dynpro ABAP transaction. However, you need to keep in mind the following points while developing custom RF transactions:

1. The size of each screen should follow either the 8x40 or the 16x20 screen format.
2. Any warning or error message should be displayed in a screen rather than in a status bar. When you run an SAP transaction on a desktop, you use SAP GUI and messages are displayed in the status bar at the bottom of the screen. However, when you run an RF transaction on an RF device, you use an RF industrial browser. You don’t have a status bar available. You have only a small screen and all the information needs to be displayed on the screen. You need to create one screen that can be used to display error messages for all RF transactions. This screen only has one screen element to display the error text.
3. You should provide a button for each action to be performed on a screen. Other than buttons and screen fields, no other screen element, tool, or menu bar should be included. The space available on an RF device screen is very small so you should try to limit the number of fields and buttons that are displayed.
4. Each button on a screen should be mapped to a function key. Users should be able to navigate between screens either by clicking a button or pressing a function key.
5. You should use only the following screen elements that are supported by ITSMobile:
   Text field, Input/Output field, radio button, check box, pushbutton, frame, drop-down list, step loop, or subscreen area. Refer to the SAP Note 1037715 (ITSmobile: Supported screen elements).

Figures 3 and 4 show two common RF transactions, when you run them inside SAP GUI: bin-to-bin stock transfer and material inquiry. Figure 5 shows how error messages should appear on the screen. As mentioned before, these RF transactions are developed as Web Dynpro ABAP transactions with a limited number of fields displayed on a screen and the screen sized to fit on an RF device screen.

Figure 3

Bin-to-bin stock transfer used to move products between storage bins in a warehouse

Figure 4

Material inquiry RF transaction used to check the location (storage bins) where a product stock can be found in a warehouse

Figure 5

Message screen showing how messages should be displayed for an RF transaction screen

Create Services, and Generate and Test HTML Templates for RF Transactions

Once you have identified and made available the RF transaction to use, which can be either a standard SAP or a custom developed RF transaction, you are more than half way to your goal. However, since these RF transactions are developed as SAP dialog transactions, you can run them only using SAP GUI. If your ultimate objective is to run these RF transactions on an RF (handheld or vehicle mounted) device, you need to generate an HTML template for the RF transaction and publish the template using Internet services. To do so follow these steps:

• Step 1. Create the ICF service
• Step 2. Create the Internet service, and create and publish HTML templates for the RF transaction
• Step 3. Test the RF transaction on an Internet browser
• Step 4 Deploy the RF Transaction on the RF Device

Step 1. Create the ICF Service

To create an ICF service, use transaction code SICF and enter the Service Path parameter as shown in Figure 6. This parameter is always the same.

Figure 6

Enter the service path

That takes you to the folder where you can see the SAP-provided ICF services (Figure 7). If you are creating an ICF service for the first time, it may be a good idea to test one of the SAP-provided ICF services (e.g., itsmobile00) to make sure you can access the SAP system using the HTTP protocol (Web browser).

Figure 7

List of SAP-provided ICF services

To create a new ICF service, place the cursor on the node “mobile” and click the “Create Host/Service” button (Figure 7). This takes you to the screen where you enter the service name and select the service type (Figure 8). Select the Independent Service radio button.

Figure 8

Enter the service name

Once you enter service name and type, click the enter icon. The screen in Figure 9 appears.  Here you first enter the description of the service in the Description 1 field. Then go to each tab on this screen and maintain the configuration data. Under the Service Data tab click the GUI Configuration button. A screen pops up (Figure 10) where you maintain service parameters.

Figure 9

Create ICF service: Service description and configuration data tabs

For example, for the parameter TRANSACTION, I entered the value LM01. This means that when this ICF service is started it starts transaction code LM01. Note that you can also enter transaction code LM00, which eventually calls transaction code LM01. Transaction code LM00 is where you enter the screen size of the device. You may not be required to do this in all cases.

Figure 10

GUI configuration

Following are details of the service parameters:

1. ITSMOBILE tells the system that this service is meant for a mobile device and the SAP Internet Transaction Server (ITS) sets up the service for a mobile device.
2. TRANSACTION defines the transaction that should start when a user logs in using the service.
3. SOURCES: When you run an RF transaction on an HTML browser or an RF device, the SAP system needs to find the HTML template for each RF transaction screen. HTML templates are contained inside an Internet service. In the SOURCES parameter you enter the names of the Internet services where the HTML templates are included so that the system knows where to go and fetch the HTML templates.
4. THEME defines a set of all templates for the application you are implementing. When searching for a template for the application, the system looks for templates under the folder you are using.

The above four parameters are mandatory for creating the Internet service.

The parameter CLIENT is an optional parameter that you can use to set the client number where the user should log in. Users also have the ability to change the client number on the logon screen. There are other optional parameters that I do not cover here.

After entering the SAP GUI configuration parameters, click the enter icon and go back to the screen shown in Figure 9. Click the Logon Data tab. Under this tab (Figure 11), select Alternative Logon Procedure as the procedure and make sure that only Logon Through HTTP Fields (also known as Fields Authentication) appears on the Logon Procedure List.

Figure 11

Logon Data tab

Click the Handler List tab. The opened tab is shown in Figure 12. Enter the class CL_HTTP_EXT_ITS, which is an SAP class that has methods to handle any incoming HTTP requests.

Figure 12

Create ICF service: Handler List tab

Now, go to the Error Pages tab and click the Logoff Page tab (Figure 13). Here you enter HTML code under Explicit Response Time > Explicit Response Page Body. This gives the user the option to go back to the RF logon screen (or start of the Internet service) after they have logged off. You can accomplish this by entering the HTML code as the Explicit Response Page Body. If you review the HTML code (Figure 14), you can see that it includes the URL that points the Internet service that I am creating here.

Figure 13

Error Pages tab

Figure 14

Create ICF service: HTML code for logoff page body

After you have completed the above steps, save the changes you have made by clicking the save icon  and then go back by clicking the back icon . Activate the ICF service by right-clicking on the service name and then select the Activate Service menu option (Figure 15).

Figure 15

Activate ICF service

Step 2. Create the Internet Service, and Create and Publish HTML Templates for an RF Transaction

Now you create the Internet service and use it to create an HTML template for each RF transaction screen. At this stage you have created and configured the ICF service. Next you need to create an Internet service using object navigator SE80 so that you can create and publish HTML templates. In transaction code SE80, select Internet Service. Click the display icon  next to the service name (Figure 16).

Figure 16

Create an Internet service

The system displays a message saying that the service does not exist and asks if you want to create it. Click the Yes button in the message box in Figure 17 to create the Internet service

Figure 17

Click the Yes button to create the Internet service

Double-click the service name ZTEST_RF (Figure 18) to display the parameter screen on the right side. Click the change icon  and enter the same parameters that you entered when you created the ICF service.

Figure 18

Define the parameters

You have created the Internet service. Now, you create the HTML template for the RF transaction under this Internet service. Start transaction code SE80, enter the program name for the RF transaction, and expand the Screens node (Figure 19). Right-click a screen number and from the pop-up menu select Other Functions > Create Template.

Figure 19

Create the HTML template for RF transactions

Once you select the Create Template menu option you see the pop-up box shown in Figure 20; here you enter the following data:

• The name of the Internet service
• The theme
• The generating Style

Figure 20

Create the HTML template for the RF transaction

Click the Save button and the system automatically creates the HTML template. Once the HTML template is created, it shows up under the Internet service (Figure 21). You can display the HTML template by double-clicking the template name. The HTML template contains HTML code that is required to display the screen and mimic all its functions in an Internet browser. You must have an HTML template generated for each screen of the RF transaction that you plan to run on an RF device.

Figure 21

Display the HTML template for the RF transaction

Step 3. Test the RF Transactions on the Internet Browser

Now you are ready to test your Internet service and RF transactions on an Internet browser located on your desktop. Use transaction code SICF and go to the node where you see the service you created listed. Right-click your service name and select the menu option Test Service. This launches the service in an Internet browser (Figure 22). Enter the SAP User name and Password and click the Log On button. You can change the client number if you wish to. This may be useful for an SAP support team that is testing the RF transaction and wants to test it in a specific client.

Figure 22

Test the RF transaction: logon screen

Once you have entered your logon credentials, you are taken to the page that looks like the screen in Figure 23. Recall that I entered transaction code LM01 as the start transaction. Figure 23 is the HTML template for transaction code LM01. LM01 is a dynamic menu transaction. The menu transaction displays the list of sub-menu options that in turn point to RF transactions that are assigned to run in the current SAP system.

Figure 23

Test RF Transaction: main menu

The 1.Inbound Proc. sub-menu option points to the bin-to-bin transaction shown in Figure 24 as seen in the Internet browser.

Figure 24

Test RF Transaction: bin-to-bin transfer transaction

Step 4. Deploy RF Transactions on the RF Device

Once you have tested the RF transactions using the Internet browser, you can deploy and run them on an RF device in the following steps:

1. Install an industrial browser on the RF device. The reason I recommend using an industrial browser is that it comes with a feature that allows you to hide all the tool bars and menu bars that you see in an Internet browser. When you run the RF transaction on the RF device the only thing you see on the RF device screen is the RF transaction screen.
   
   You can only use the functions available inside the RF transaction and cannot abruptly close the browser or switch to another application on the RF device. This is important because the typical RF user is a warehouse operator who may never have worked on a desktop computer. Using an industrial browser to display RF transactions on an RF device makes life easier for the user. Your IT department should be able to install the industrial browser on the RF device.
2. Configure a pocket browser to start the RF transaction automatically. This task should be done by the IT support staff. The only thing you need to provide is the URL of the Internet service, which you can copy when you launch the Internet service. The IT staff includes the Internet service URL in the configuration file of the industrial browser so that as soon as you launch the industrial browser application on the RF device, it launches the Internet service automatically.
3. Configure the RF device to automatically launch the pocket browser when the RF device is powered on. You can skip this step if you don’t want to launch it automatically. IT support staff should be able to perform this step by referring to the industrial browser’s user guide.

Modify HTML Templates

Once users start testing the RF transactions they may request some cosmetic changes to the RF transaction screen. You can do this by tweaking the HTML template and thus avoid changing the underlying SAP dialog screen. Some examples of changes that you can do this way are deleting blank lines on the screen or moving screen elements, such as buttons. You can address these kinds of changes by modifying the HTML code in the HTML template. You need to be somewhat familiar with the HTML syntax in order to do this.

To delete a blank line on a screen, look for the lines of code shown in Figure 25 in the HTML template and delete them.

Figure 25

Modify HTML templates: delete blank lines on HTML screen

To reduce the field width, look up the field name from the SAP GUI screen and change the colspan value for that field in the HTML template (Figure 26).

Figure 26

Modify HTML templates: adjust field width

Appendix: Lessons Learned from RF Transaction Implementation Projects

It is worth keeping in mind the following points while planning and executing RF transaction implementation projects:

1. Selecting RF devices: Selecting an RF device and an industrial browser is an important step of the project. Start this selection process as early as you can, preferably while the project team is working on RF transaction development and configuration. Plan on asking your supplier to send you few sample RF devices so that you can try them out before placing the actual order. The Motorola MC9090 is a good example of a RF device that I have seen being used by many customers. I would recommend that you select a RF device that runs Microsoft Windows CE.
2. Configuring RF devices: You should have your RF devices configured before you start the user acceptance test (UAT) of the RF transaction. This is done by your IT support staff. Make sure you have resources and time planned for this task as part of your project plan and have this task completed before the planned start date of the UAT. Make sure that the industrial browser is installed and configured so that when you power on the RF device it starts the industrial browser automatically. The industrial browser manual should tell you how to accomplish this. The URL for the ICF service (e.g., /sap/bc/gui/sap/its/test/mobile/ZTEST_RF) needs to be placed in the industrial browser configuration file. This way when you power up the RF device it automatically launches the industrial browser which, in turn, launches the ICF service for the RF transaction. The user doesn’t have to worry about what program to start when powering up the device. As soon as users power up the RF devices, they see the SAP logon screen on the RF device screen. This provides a seamless user experience.
3. Testing RF devices: You need to run each RF transaction on the RF device using the industrial browser to make sure that the transaction screens fit in the RF device screens and all screen elements are visible. After completing this round of testing you need to install wireless access points in your warehouse and walk all over the warehouse and try to use your RF device to make sure that you have good a wireless signal available and that the RF transaction session is not lost due to a weak wireless signal.

Atul Mehrotra

Atul Mehrotra is the manager, remote delivery, with itelligence, inc., an NTT data company. Atul started his career with SAP in 1996 and since then he has worked in various capacities including as a developer, development team lead, technical project manager, and technical solution architect in over 20 SAP implementation projects. In his current role Atul serves as technical solution advisor, mentor, and organizational leader for managing near shore and offshore process and operations in itelligence.

You may contact the author at atulm2@gmail.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.