Skip to Content

In my first blog post I would like to share some experiences on implementing the Hybrid Web Contain (HWC) on BlackBerry devices through Sybase Unwired Platform (SUP) better known as the future SAP Mobile Platform (SMP).

Landscape back ground:

  • Solution: Mobilizing of SAP workflows onto BlackBerry
  • Platform: SUP 2.1.3
  • Mobile devices: BlackBerry OS 5, OS 6 and OS 7
  • Back-end integration: SUP connect through BAPI interface into SAP

1. HWC: Out of memory

You might experience an “Out of memory” exception while using HWC. This happens quite frequently on OS 5 and OS 6, even though there are not a lot of memory consumed by resource on the device. The “Out of memory” exception might occurs less on OS 7 as SUP 2.1.3 has build-in code to handle this exception better.

The exception occurs in the under lining RIM libraries and is not a SUP issue. Confirmation from RIM is that this issue will be resolved in OS 10.

2. BlackBerry OS 7 not succeeding making initial connection to SUP server for registration

You might experience when registering a BlackBerry OS 7 device with SUP, that the initial connection does not happen. Because of the initial connection not happening you will find no information in the server logs. Looking at the device logs will reveal very little to the underlining problem.

In my case to resolve this I made sure that I use the latest HWC files on the device and I upgrade the device from OS 7.0 to OS 7.1

3. BlackBerry Push Technology

You might find when making use of BB Push Technology that the notifications do not arrive in a timely fashion on the device (in my case it took sometime up to 10 minutes), or the notifications never arrives on the device.

First of all make sure your Push Service URL is correctly configure in Sybase Control Center (SCC). If your service requires authentication ensure you configure the credentials correctly:

BBpush1.JPG

After a BlackBerry device has registered with the SUP server you will notice that SUP allocated a Push Listener Port to the device where all push notifications from the BlackBerry Enterprise Server (BES) will be received. In SCC select the user / device under the Application Connection tab and click the Properties button:

/wp-content/uploads/2013/02/bbpush2_188047.jpg

You will notice that port 5011 (in the picture above) has been allocated by SUP. Also you will find that you can not change this port number. For each new application connection registered SUP assigns a different port – At a customer of mine SUP cycled through assigning ports 5011, 5012, 5013 as connections are registered. You can see the challenge here – How will the BES knows to which port it should send the notifications?

As the BlackBerry devices are registered with BES at the customer, a small configuration change needs to happen on BES for the Mobile Data System (MDS). With in the BES installation path look for …\MDS\config\rimpublic.properties file. Edit the rimpublic.properties files.

It will look like this:

/wp-content/uploads/2013/02/bbpush3_188122.jpg

Within the configuration file find the entry “push.application.reliable.ports” (as indicated above). If there is a “#” in front of the entry, remove it to un-comment the line. If SUP allocates a port for example 5014, you just add this port number to this line.

NB: Remember to restart the MDS service after any modifications to the rimpublic.properties files.

NB: The above configuration is not applicable to BES10

*If you still experience latency problems look at the priority of application notifications on the BES.

4. Alternative to BES Push Technology

You might find yourself in an environment where the network infrastructure is not very stable or even unreliable. The alternative to push technology is switch your workflow application to “online”, which means that the solution doesn’t rely on the BES to deliver the notification but the HWC stay online connected to SUP:

bbpush4.JPG

Again, select your application connection and click the Properties button in SCC (shown above). Set the Enabled value to False for BlackBerry Push Notifications. The HWC will stay online. I have implemented a solution in this fashion and the impact of being online on the device battery is minimal and barley noticeable.

5. Workflow controls not functioning as intended

You might find that certain controls function perfectly on a touch screen device but fails on a non-touch screen device. In my case the listview did not work on a non-touch screen 9300 using the BlackBerry navigation button.

To get around this you need to add custom code to the workflow generated files.

In my case I had to modify 2 files:

API.js

bbjs2.JPG

A new function needed to be added to the API.js for the BlackBerry 9300 (see above)

listview.js

bbjs1.JPG

The event “touchend” in sy.ui.iphone.listview.js (yes, BlackBerry uses the same javascript files as iPhone) was modified to include the Blackberry 9300.

NB: Keep in mind that when you generate your workflow that you un-tick the “Update generated code” (see below), otherwise the above custom changes will be overwritten and lost.

bbjs3.JPG

Hope this was informative to you and you are welcome to leave a comment.

Happy coding,

Daniel

To report this post you need to login first.

10 Comments

You must be Logged on to comment or reply to a post.

  1. Midhun VP

    Nice Blog Daniel. I am leading a similar kind of project for my customer in BB. I got few questions:

    • Which approach will be suitable: using BES push technology or the alternative way you given? You mean “online” the cache policy of the MBO ?
    • The app is a workflow with 3 levels of approval. I am implementing DCN with payload, in that case how to identify to which user the push notification to be reached? in the “to” field of the JSON I am keeping “supAdmin” then the notification is reaching to all the devices which are using this application. Can you please let me know the solution for this if you had faced these challenges.

    Thanks

    Midhun VP

    (0) 
    1. Former Member Post author

      Hi Midhun,

      Glad to here you find the post helpful.

      1. Just to clarify – Working with workflow your cache policy will always be online.

      2. When you switch push notifications off (false as shown above), the HWC will always stay connected and will never go into “sleep mode” or “idle mode”.

      3. The best approach is to make use of the push notifications from BES to “wake up” the HWC and to instruct it to connect to SUP as there is work waiting in the queue.

      4. The alternative approach can be used when you have BES / Infrastructure challenges and you are pushed for time. (see this as a work-around)

      5. Regarding your second point:
           a. My first impression from reading your question is that the message goes to multiple devices points to a configuration issue. > Please send more detailed information on this process.

           b. What is your reason for using DCN with payload? I need to understand more to be able to assist you.

      Regards,

      Daniel

      (0) 
      1. Midhun VP

        I don’t have a specific reason to use ” DCN with payload “. I followed the following post and in that it was based on ” with payload “. http://scn.sap.com/community/developer-center/mobility-platform/blog/2012/06/11/calling-the-sup-data-change-notification-from-abap

        Later today when I read some other blogs I found that in the practical scenario we need to activate the user for workflows from the application through the use of one time activation screen. In that case the “to” field in the JSON message will be dynamic and may solve my issue.

        http://scn.sap.com/thread/3257994

        http://infocenter.sybase.com/help/topic/com.sybase.infocenter.dc01182.0120/doc/pdf/smw_windowsmobiledeviceuser.pdf

        http://scn.sap.com/thread/3378325

        Can you please give a solution for this issue

        Please let me know if you want anymore information.

        Thanks

        Midhun VP

        (0) 
        1. Former Member Post author

          Hi,

          The “to” field should contain your application connection OR username that was used with device enrollment in SUP.

          If you device users are registered within SUP with their SAP username, you should populate the “to” field with the same username. SUP will route the message accordingly.

          Daniel

          (0) 
            1. Former Member Post author

              1. “The user changes means” – do you mean user name change?

              2. For different levels of approval:
                   a. At a customer the whole workflow and levels are managed by the SAP back-end (SAP workflow), which makes life easier. (Is this a possibility at your customer?)
                   b. SUP doesn’t care about level, the same process gets repeated for every workflow message.
                   c. SAP determines who the next user in the chain is and post a DCN to SUP for that user. SUP will then route the message to the corresponding device.

              Daniel

              (0) 
              1. Midhun VP

                Thanks for your response Daniel,

                1. I meant the user as the user name ( registered user ) we are providing in the “to” field. In the sense right now we have only 5 users for this workflow and after few months it may be 10, in that case an ABAP guy is need to add the 5 new users in the “to” field right. It won’t be a right approach right.

                2. Yes in the customer level a workflow is configured. My question is how SAP will route the message to the correct user? The DCN message only reaches to the user who are present in the “to” field right.

                Let’s say there are 3 levels. employee, Manager and Director. Let’s keep the names of the registered users are “employee”, “Manager” and “Director”. Once employee approves the notification should reach the “Manager” and once Manager approves the notification should reach the Director. In this case what names should I keep in the “to” field of the DCN?

                Thanks in advance.

                Midhun VP

                (0) 
                1. Former Member Post author

                  Hi,

                  1. The “to” field is populated with the user name dynamically within your BAPI, no hard coding. You will only have one line of code in the BAPI making the DCN call to SUP this line of code will be used for every single user. DON’T hard code the user name in the DCN call..

                  2. SAP will route to SUP by calling the DCN url on port 8000. This is a service running on your SUP server.

                  The process within SUP is the same for each and every level of approval. The DCN call from SAP will insert a record in the queue against the user name (“to” field”). The message will go to the device registered within SUP with the same user name.

                  Daniel

                  (0) 

Leave a Reply