I got introduced to Object Queries rather by "accidental discovery" while trying things out at the SUP Trial server.
After going through the first two tutorials at the SUP Trial server, I decided on trying to build a simple prototype app that would get list of background jobs from the SAP ECC system and show their current states. A imagine that a real mobile app that would be used to monitor background jobs would have information as to average runtime vs current runtime of the job and alerts for job failures and ETC breaches aside from being able to go through the list of background jobs. For now, though, the basic job list is fine with me.
I start out by looking for a BAPI/RFC that would fetch the list of background jobs from the SAP ECC system. After a while I settle on the following call:
BAPI/RFC call to fetch a list of background jobs from the SAP system
I'm only interested in showing jobs with the Aborted, Running, and Finished background job states whereas for the From and To Dates I decide to just hard-code the date range for this prototype - hence at the Load Arguments tab I set the value 'X' for the three job states and settle on a 3-day date range. Based on experience in using the SAP transaction SM37 I also placed the value '*' as a wildcard for the Job Name and User Name parameters in order to get all the jobs within the 3-day period for the three job states. The resulting Load Parameters look like this:
Load Parameters
At the Attributes Mapping tab I decide to retain only the fields Job Name, Status, Start Date, Start Time, End Date and End Time to keep the results compact so that I could fit more records in the screen at one time. I also decided to select the first 4 fields to also be the primary key to see how it would affect the MBO. After saving the changes I found the following at the Object Queries tab:
The Object Queries tab
And it was at this point that I got introduced to the Cache Database.
Before seeing this the impression I got after doing the tutorials was that the BAPI/RFC call was done every time the event for it was triggered at the device and the results for it would always be sent to the device and then immediately displayed. Instead what I learn is that the results from the BAPI/RFC call are saved in what is called a Cache Database (or CDB for short), then downloaded to the device local database. The downloaded data (or a subset of it) is then fetched for display by running an Object Query.
Eager to try out a bit of the scheme I built the resulting JobViewer app such that it would return two kinds of results - the first one is unfiltered and would come from the FindAll query and one that was filtered by Job Status. For the filtering by Job Status function, I would like to implement it by providing a Choice control wherein the user could pick which background job state to query results for. The resulting workflow is very similar to the one created by following the tutorial.
The JobViewer Workflow
I added an additional screen to the flow wherein I placed the Choice control (and a 'Go' button to trigger the object query) so that the start screen would not look cluttered by having only two buttons - one for triggering the FindAll query and the other to navigate to the screen that had the FindByStatus query. The screens that would display the results were auto-generated just by dragging the Jobs MBO to the FlowLogic work area. I then 'wire' the FindByStatus object query to the 'Go' button of my "Jobs By Status" start screen and go to the Parameter Mappings properties section of the button to find....
Parameter Mapping for the FindByStatus Object Query
...the Object Query parameter STATUS (":STATUS" at the Object Query SQL). I map this parameter to the Input Data Binding Key (called StatusKey) of my Choice control, saved and generated the Mobile Workflow package, then fired up the Android Emulator to give the new JobViewer app a test run.
The JobViewer Start screen
After the Start screen appeared I clicked on the "Show All" button to ensure that the BAPI/RFC call was fetching all of the background jobs (shown below). Most of the background jobs that were returned had the Status 'F' (for Finished) although there were a number of jobs that aborted (signified by 'A'). Although I didn't catch any jobs that were currently running I knew from the two other job states I saw that nothing was getting filtered out.
Sample results from the FindAll Object Query
I then went back to the start screen and clicked on the "Show By Status" button to navigate to my Find By Job Status screen which had the choice control for Job states. I picked the job state "Canceled" (aborted jobs are shown in the SAP background job monitor with the same word as its job state), hit "Go" and got only the aborted jobs in my results screen.
The "Jobs By Status" query screen
Results from the FindByStatus Object Query
I hope this leads you (as this exercise did to me) to learn more about the CDB and how data can be synchronized and refreshed between back end systems and mobile devices. Have fun everyone.
