Dev Tip: Checking Network Calls in Chrome

To sign up and get your dev tips delivered to your inbox each week, click here!

Tip of the Week

Checking Network Calls in Chrome
Often times, in the development of UI5 applications, the team will have a UI developer, creating the application using the UI5 libraries, and the WebIDE, and a Gateway developer, creating the OData services that the application will consume. As the UI developer, scenarios will sometimes arise where you notice issues in the data. Perhaps data we expect to be present is not showing up, or maybe something like the approval of a document, or creation of something like a material, is not working as expected. Before you call in the Gateway developer to check the backend code, it’s helpful to do a little debugging on the UI side to see where the problem really is. The Chrome debugger will help us debug the network calls to see what data we are actually sending and receiving. To access the debugger, use the menu shown in the screenshot below.
With the debugger open, we want to navigate to the “Network” tab as shown below.
Now, let’s open an application to see some of the OData calls being used. For this demo, we will use the “Approve Requisitions” application.
We can see all of the OData calls that happened when we clicked on the application in the network tab of the debugger on the right side of the screen. Clicking a particular row will give us additional details. I will select the one named “WorkflowTaskCollection”.
The headers tab shown here provides information like the request URL, the request method, and the return status. This is a “GET” call, meaning it’s fetching information. For something like a “POST” call, that may be creating something, a material, for example, the headers section will also show the request payload, or the information being passed back to create that item.

There is also the preview tab which we can use to see the data returned by the OData service, as shown below.
We can see that this first result, created by “Nelson Negotiator”, with a value of “1,860 USD” lines up with the data we see coming back from the OData service. If for some reason the value “USD” was not showing up, it may very well be a UI issue because we can clearly see that value for the field “Currency”. However, if we expected there to be a “ForwardedByID”, we may need to have the Gateway developer debug their code to figure out why this isn’t being populated, as we can see it’s being returned empty by the OData service.

Overall, being able to perform this type of debugging will help you understand if data issues reside on the UI or OData side. Additionally, it will help you to provide more context for the Gateway developer if you do notice anomalies. You could easily send the exact request URL, any payload, and the response data, by taking screenshots as we did for this blog. This will help them replicate and debug the issue much quicker.

 

 

If you have an interest in viewing similar content, visit our blog, here. 

View our LinkedIn, here. 

Dan Flesher is an experienced SAP UX Architect and Design Thinker. He began his SAP career as an ABAP developer, and transitioned to a focus on SAPUI5 and Gateway OData service development. In addition to his development background, Dan has a passion for Digital Transformation, and Design Thinking, helping clients with their trickiest challenges. With a user-centered focus, Dan is typically involved in all stages of projects, from design workshops and prototyping, through development and delivery. Dan is a frequent speaker at ASUG and SAP UX events, and contributes blogs and development tips through the SAP UX newsletter and the Mindset blog.

Back To Top