> For the complete documentation index, see [llms.txt](https://docs.prebilt.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.prebilt.com/prebilt-for-im-wm-strm/enhancing-prebilt/connection-to-sap.md).
# Connection to SAP
This section will detail how the frontend connects to SAP through AJAX calls.
## Connection to SAP
The functions callAJAX and postAJAX are used in other AJAX call functions to find the method and to make the connection to SAP.
CallAJAX is used to call the corresponding method in the backend, for example in each app there is a callAJAX to the function “GetSetup”.
Another common AJAX method is SELECT, using the callAJAX function for SELECT will call the ajaxSelect function. This function in turn calls the postAJAX method for SELECT which triggers the SELECT method in the corresponding ABAP class.
When this method is completed any AJAX error in the call back will be handled by errorCB, e.g., a failed connection to SAP. However, if the method has completed it will trigger successCB and in turn selectSuccess. This will then handle any logic needed in the frontend depending on what response code was returned from SAP, which is stored in the SelectResp model. E.g., `gm("oSelectResp").getData().STATUS`.
## Standard Response Status Codes
After the connect to SAP has been made, the call will return a status code in the response. In PreBilt some of the status codes are reserved for standard responses:
* 0 - This is the standard success code, some functions have more than one success status depending on what data has been sent to the backend and what functionality is required by the frontend.
* 1 – This is the standard error status. This usually doesn’t have custom code to handle it in the frontend but will call the handleMessages function to display any messages in the responses MESSAGES section.
* 5 – This is another success status code and means that a Selection Opt List has been sent from the backend, the code in this status will then call the function processSELOPT\_LIST with a callback function as a parameter to continue the processing.
* 80 – This has been reserved for serial numbers and often includes logic to jump to the serial number app.
* 90 – This status code is reserved for any field validation issues, this status code usually has no custom code to handle it in the frontend but will call handleFieldValidationUpdates to display the field validation issues based on the data in the FIELD\_VALIDATION section of the code.
## Response Models
In our ABAP methods we define a global structure called \ which allows us to pass fields to the frontend.
\ will always return:
* \-status handles a status (as seen above)
E.g. the following returns an error status (1)
\-status = /tctm/if\_wm\_app\_srv=>gc\_status\_field\_err.
* \-messages handles any messages.
Other fields we may want to pass to the frontend can be found in the corresponding TYPE (ty\_\*\*\*\_resp).
With a successful AJAX call to SAP, we trigger the Success part of our function. This will have the naming convention “method\_name”Success, for example our Select method will call the selectSuccess function.
Within the above Success function, we call the following block of code to parse data received from the backend into our corresponding model.
```
// Parse Response Deep Structure
sap.tctm.core.parseRespData({
data: data,
model: gm("oSelectResp")
});
```
Models are defined at the top of the FE code:
We can then access any data passed from the backend with the defined models.
```
gm("oGetSetupResp").getData()
gm("oSelectResp").getData()
```
The two examples above are for the GET\_SETUP method and SELECT method in our ABAP class, these are two very common methods/responses, but all methods follow a similar naming convention. That being o”METHOD\_NAME”Resp” and .getData() call pulls out the oData information defined in our ABAP method.
