Step 4: Calling a Function Import

We only want to display the upcoming meetings and hide the meetings happened in the past in our app. By using a function import that calculates these items on the back end we do not need to do the calculation on the client. The mock server will be instructed to do the calculation locally for testing purposes.

Preview

Figure 1: Only the upcoming meet-ups are shown

Coding

You can view and download all files in the Explored app in the Demo Kit under Mock Server - Step 4.

webapp/localService/metadata.xml

... 
            <EntityContainer Name="NerdMeetups" m:IsDefaultEntityContainer="true">
                <EntitySet Name="Meetups" EntityType="NerdMeetup.Models.Meetup" />
                <FunctionImport Name="FindUpcomingMeetups" EntitySet="Meetups" ReturnType="Collection(NerdMeetup.Models.Meetup)" m:HttpMethod="GET" />
            </EntityContainer>
        </Schema>
    </edmx:DataServices>
</edmx:Edmx>

The function importwe are going to use is declared in the metadata.xml file.

webapp/view/View1.view.xml

...
    //Delete items="{/Meetups}"
	<List headerText="Upcoming Meetups" id="list1" items="{/FindUpcomingMeetups}" 
...

We change the binding of the list to a function import call that returns only upcoming meet-ups, instead of the call to the entire meet-ups collection.

After saving and running the app again, we should get the following result:

Figure 2: No data visible

Since the function import call is not simulated automatically by the mock server, we do not see any data in list, and a failed network call is issued in the developer tools of the browser.

Tip

In Google Chrome, mocked requests will appear in a debug level log of the console (both request and response) and not on the Network tab. If you do see them in the Network tab, they are not mocked and you need to check your code.

In order to simulate the function import call, we write our own (mocked) implementation, and add to the internal list of requests.

webapp/localService/mockserver.js

...
oMockServer.simulate("localService/metadata.xml", {
	sMockdataBaseUrl : "localService/mockdata",
	bGenerateMissingMockData : true
});
var aRequests = oMockServer.getRequests();
aRequests.push({
        method: "GET",
        path: new RegExp("FindUpcomingMeetups(.*)"), 
        response: function(oXhr, sUrlParams) {
        	jQuery.sap.log.debug("Incoming request for FindUpcomingMeetups");
        	var today = new Date();
	 	today.setHours(0); // or today.toUTCString(0) due to timezone differences
	 	today.setMinutes(0);
	 	today.setSeconds(0);
        	var oResponse = jQuery.sap.sjax({
               	url: "/Meetups?$filter=EventDate ge " + "/Date(" + today.getTime() + ")/"
        	});
        	oXhr.respondJSON(200, {}, JSON.stringify(oResponse.data));
        	return true;
        }
});
oMockServer.setRequests(aRequests);

var fnCustom = function(oEvent) {
...

We push a new request handler to mock the function import call as follows:

Fetch the array of requests from the MockServer. The mock server holds an internal list of requests that you have to get and set if you want to modify.
Push a new request handler to handle the function import
Set the updated request array

The request handler has the following structure:

method: The HTTP method of the mock request
path: The relative path (appended to the rootUri) of the request.

We can define the path as a regular expression, for example, to handle URL parameters.
response: A response function that simulates the answer from the server

The response function executes a request to the Meetups entity set with an OData $filter query that actually returns all meet-ups with EventDate that is greater than or equals today. We compose a date for the filter and send it to the server manually as a synchronous request.

It is o.k. to use jQuery.sap.sjax here, because the call will not actually leave the client. It triggers a new request that again is intercepted and processed by the mock server.

We finally respond on the XHR object by calling the respondJSON API. It will add the proper content type header for the JSON format and send the result. We provide the HTTP status code 200 (success) and the 'stringified' response data as the arguments. Returning true at the end of the function indicates that we have completed the processing of the request in this handler (no additional request handlers should be checked for that request).

When you now start the app again you will see a list of upcoming meet-ups.

Creating and Editing Mock Data in SAP Web IDE (Optional)

webapp/localService/mockserver.js

...
oMockServer.simulate("localService/metadata.xml", {
	sMockdataBaseUrl : "localService/mockdata",
	bGenerateMissingMockData : true
});
...

The path we gave in the simulate function for mock data is where we want to store the .json file(s).

Save it (in JSON format) from a real service
Create it manually
Generate it in SAP Web IDE by choosing Edit Mock Data in the context menu of the medatdata.xml file.

For more information, see Editing Mock Data in the documentation of SAP Web IDE

Figure 3: Editing mock data in SAP Web IDE