The following blog discusses two scenarios for deploying an application to a physical handheld. The first is when testing during development. The second is when deploying to a production device. Finally, an overview of upgrading a handheld with a new version of the application is given.
Please note that I've worked entirely with Windows Mobile devices and I'm assuming that the procedure described below applies to other devices as well.
Scenario #1: Local Deployment: Deploying to a physical handheld for testing
Prerequisites and assumptions
Firstly, I am going to assume that you've developed and been testing an application in NWDS. Through NWDS, you've been able to load your application in the NWDS emulator and verify that it works. Perhaps, you’ve also set up a logical device in the DOE and have been able to sync. You are now ready to deploy to a physical device.
Secondly, I will assume that you have access to the device's file system, perhaps through a USB docker. For more information on connecting a Windows Mobile handheld to a PC through a USB docker, please see my earlier blog on the subject.
Overall, we will be copying the deployment files from the "inbox" of your NWDS emulator to the handheld's "inbox".
Instructions
1) Identify path to deployed application
Find the MI deployment path in NWDS. Under "Preferences" go"Mobile"->"Handhelds"->"Runtime Settings". Here you will find the client installation path. If you are using the defaults, it is likely to be something along the lines of "C:\Program Files\SAP\IDE\CE\eclipse\plugins\com.sap.tc.mobile.dt.oca.rt\MI\inbox"
2) Identify the path to the handheld inbox
This is likely \MI\inbox on your handheld if you are using default settings.
3) Deploy the application
Through NWDS, deploy the application and all of its components.
Using your favorite File Explorer, browse to the path identified in (1). You will notice some .sda files and some xml files. Copy all of these to the handheld's inbox as defined in (2)
4) Start the Netweaver Mobile Client on the handheld.
Please be patient since the handheld is much slower than the NWDS emulator and may take a while to deploy your SDA's.
5) Get data (optional)
You can now sync data down from the DOE if it hasn’t already been done. You will need to create a logical device and assign the required DM SWCVs.
Notes and Considerations
Generally I try to avoid testing on the physical handheld because it is significantly slower than the NWDS emulator. Clearly, though, testing must be performed on the actual device before it can be rolled out to users. While unusual, there are issues that will occur on the device that will not occur in NWDS. These issues are especially prevalent when dealing with custom controls.
Further, be aware that you can redeploy changes to the handheld by recopying the new deployment files the handheld’s inbox. New code will simply overwrite the previous deployment.
Scenario #2 Remote Deployment: deploying to a production device
The application has been tested and is now ready to be deployed to an active device in the field. This deployment method can be used when testing and is valuable anytime you want to use the DOE to deploy the same code to many devices at once.
Prerequisites and assumptions
It is assumed that the application has not yet been deployed to the device. It is also assumed that a logical device has already been created and that the device has already registered with the DOE.
Instructions
1) Find your SDAs
Find the path of the of each component project to be deployed. This can be done by viewing the properties of the project under NWDS. Change the perspective to “Resource” or “Java” and right click on the project -> “Properties”. This might give you a path along the lines of “C:\workspace.jdi\1\DCs\mycompany.com\my_project\_comp”. From there, the SDA can be found in the “\gen\default\deploy\” folder. This should be done for each component including service, UI and application components.
2) Upload SDAs to DOE
Use transaction “sdoe_upload_archive” in the SAP GUI. In my environment, I have to connect to the DOE directly rather than through my usual R3 SAP GUI.
From there the SDAs can be uploaded.
A note on naming: the component uploaded was called an “SDA”. Now that it is in the DOE, it is called “MCD”. I’m not really sure why the naming difference exists.
3) Change state of MCD’s to “Tested”
From the web based DOE Administrator (using IE or Mozilla or whichever) under “Administration”-> “Mobile Component Administration”.
Find the component by hitting “Go” and click the linked name of your component (under the “Mobile Component” column). It might be advisable to use the advanced search to find the component more quickly. Hit “Advanced”, select a “Component Type” of application and a “Status on DOE” of “Untested MCD”. Hit go and it(they) should show up.
In any event, once the Mobile Component Details are visible, hit “Change State” on the right. Select “Testing Succeeded” and a hit “Change State”.
Note: If you re-upload an SDA with the same version, the state of that MCD will change back to “Untested”. When re-uploading, the old MCD is replaced with the new one. Any device that had downloaded that old MCD will continue to operate without knowledge of the change.
4) Assign MCD’s to devices
Again, through the web based DOE Adminsitrator, from “Mobile Overview” , “Manage Device” you can select the logical device you want to assign the new MCDs to.
Search for the device and view its details by selecting its name. From the detailed device view, select the “Mobile Components” tab and hit “Manage MCDs”. Search for the mobile component and add it to the device using the down arrow. Hit “Save”. At this point you may be prompted to assign DM SWCVs. Do so by selecting them (under “Non-conflicting DMSWCVs” on the right) and hitting “Save”. If you missed it, you can always assign them later under the “Distribution Model Software Component Version(s)” tab of the detailed device view.
Note 1: If you assign an MCD, all of its dependencies get assigned automatically.
Note 2: It is often faster and easier to create a device profile with the new MCDs and assign that profile to the handhelds rather than assign all of the MCDs to each device.
5) Sync device
Note that the application’s MCDs are downloaded and installed. You can observe the state of the deployment through the “Mobile Components” tab of the detailed device view.
Notes and Considerations
I usually avoid this deployment method during development because of the extra steps involved in configuring the DOE.
Also, you may find the deployment state of the MCDS a bit confusing:
- “Installation Initial” means the device has not yet downloaded the components
- “Installation Pending” means the device has downloaded and installed the components, but that the installation has yet to be confirmed by the DOE.
- “Installed” means that successful component installation has been confirmed.
Scenario #3: Remote Deployment: Upgrading a handheld
Prerequisites and assumptions
A handheld with an older version of the application component is to be upgraded. That handheld has had a mobile component deployed through remote deployment and now needs to be upgraded.
Instructions
1) Update the SDA’s version number.
Update versions in dpi.xml and mcd.xml . Both files can be found under “MOBILE-INF” in your project’s directory. You may need to change perspectives to “Java” or “Resource” in NWDI.
In dpi.xml, update the “version” attribute of the “mcd” node. In mcd.xml update the “mcd_version” node.
If the other components are dependent on this new component, you will need to update their references and deploy them as well. Also, I believe the newer Netweaver IDE has a wizard for these steps, although I have not tried it.
2) Upload SDA’s to DOE
This is the same step as 2) in Scenario #2 above.
Use transaction “sdoe_upload_archive” in the SAP GUI.
From there the SDAs can be uploaded.
A note on naming: the component uploaded was called an “SDA”. Now that it is in the DOE, it is called “MCD”.
3) Change state of MCDs to “Tested”
From the web based DOE Administrator (using IE or Mozilla or whichever) under “Administration”-> “Mobile Component Administration”.
Find the component by hitting “Go” and click the linked name of your component (under the “Mobile Component” column). It might be advisable to use the advanced search to find the component more quickly. Hit “Advanced”, select a “Component Type” of application and a “Status on DOE” of “Untested MCD”. Hit go and it(they) should show up.
In any event, once the Mobile Component Details are visible, hit “Change State” on the right. Select “Testing Succeeded” and a hit “Change State”.
Note: You should notice that the component with the previous version still exists in the DOE and is considered a separate independent component.
4) Assign MCDs to devices
Through the DOE Administrator and from “Manage Device” you can select the logical device you want to assign the new MCDs to. Simply select the “Mobile Components” tab. Again, it is often faster and easier to create a device profile with the new MCDs and assign that profile to the handhelds rather than assign all of the MCDs to each device.
Note: Do not unassign the old MCDs! This will confuse the DOE.
4) Sync device and note that the new application MCDs are downloaded and installed.
Notes and Considerations
Clearly, it may be tempting to disassociate the old MCDs. It is simpler to leave them and add the new ones. If you had to remove the old MCDs, follow this procedure:
1 – Remove MCDs including all previous versions
2 – Sync Device and note un-installation
3 – Add new MCDs
4 – Sync Again and note installation
