– By Robert “Seb” Meekins, SAP Technical Intern, DataXstream Summer Program 2015

Coming in as an intern for DataXstream I was given the relatively simple task of generating an ABAP monthly retail order report and being able to display it on a web page. From the outside it doesn’t seem too complicated – something that would naturally belong in an SAP retail solution, but bear in mind I had almost zero experience with JavaScript and ABAP, let alone the go-between layer of the SAP Gateway. By the end of the project, I had received several error messages in several different languages, and even caused a kernel panic on my OSX laptop. Hopefully some of the knowledge I’ve picked up can help you out as well.

For a bit of background, I was writing a monthly sales report. The user would have been able to select a month and date, and have all of the sales information for that month returned – specifically the customer number, material number, quantity, and material description for each sale. After acting on the database (either a GET, POST, or similar request) it can return the results to the webpage. Webpages using the Gateway offer a very flexible point of sale solution while still affording the powerful SAP order management solution.

• Tip #1

  : If you’re doing a GET request, and using URI filters for it, your Entity Types inside of your Data Model must include the information coming in from the filters as well as that which is going back out to the website frontend. My mistake was assuming that the information that I wanted returned were the only properties I had to define.

• Tip 2:

  If you’re using the SAP NetWeaver Gateway Client to help debug your Service (a very helpful tool) make sure that you know how to actually access the entity set you want. By default, the URI is pointed at the service itself, rather than any specific information you need. So make sure you change it from “odata/sap/Z_MY_GATEWAY_SRV/?$format=xml” to “odata/sap/Z_MY_GATEWAY_SRV/z_my_data_set/?$format=xml”. Bear in mind that the URIs are case-sensitive and need to match the name in your Data Model. If you’re using Javascript on the front-end, it will also be much more useful if you change the format tag from “xml” to “json”, because you will be able to see the structure of your data as it will be received by the Javascript on the website.

• Tip 3:

  If you’re passing in numbers from the website to the Gateway, bear in mind that Javascript integers eliminate unnecessary preceding zeroes from the variable value. This may cause problems if you’re using that value to query against the database. In my case, I needed to pull sales records based on their month filed. In SAP, that was handled as a 2-character string, i.e. “02”, but I was passing in an integer as 2. These don’t match, and I wasn’t getting any results. I ended up finding a good solution off of StackOverflow in the following function, which prepends one zero if a number is below 10 and implicitly converts it to a string: function numFormat(n) { return n > 9 ? “” + n : “0” + n;} After that point, the string I passed in was matching the format of the string in the database, and I actually got some useful data.

• Tip 4:

  Understand exactly what is going on in a GET request vs. a POST request. In my project I didn’t have to worry about posting, but understanding a GET request was still a little complicated the first time around. In a GET request, you’re doing a read-only operation. Specifically, you’re passing in constraints (filters) to the SAP Gateway, which will use those to run queries on the database and then return the information. You pass in those filters on the end of the URI. In the gateway, you access those filters using IT_FILTER_SELECT_OPTIONS. See the attached screenshot for how I accessed my month and year data out of the filters:

In conclusion, if you’re just starting out, the simple tasks can have a lot more hang-ups than you might see. Having a clear understanding of what is happening to your data at all levels of the process is vital. Once you have that, you can start to focus on the way it is processed at each level – the frontend, the gateway, or the database – and the language-specific semantics and processes. I may not have built an SAP ERP application, but a basic POS function is a great place to start.

Seb Meekins is a student at the College of William and Mary, double majoring in Computer Science and Government. Seb’s goals coming into his internship position were to learn all of the technical skills possible with the ABAP and JavaScript languages that we use in the business software/SAP industry. He says that although he had more of a background with both back-end and front-end of Java and Android, and some with Python and C, he felt well-equipped to learn the new languages needed for DataXstream’s SAP software. Seb’s individual learning assignment for the summer is focused on variant configuration, breadcrumb navigation and functionality of modules for the front-end of our OMS+ Solution.