Employing Implementation and Development Best Practices When Using Service Layer API

When you use the Service Layer API, you may perform one, or both, of the following scenarios:

1. Resource-intensive operations, which require long processing times at different layers. For example, creating marketing documents with huge line items or performing $batch operations or login operations.
2. High Concurrency, which means performing short but more simultaneous requests from different Service Layer users. For example, the end user loading the page which fires several GET requests to retrieve information.

To efficiently develop, implement, maintain, and troubleshoot Service Layer, you must have a clear understanding of the Service Layer dependencies so that you can apply the best approach for your scenario.

1. Service Layer landscape

   Service Layer is the central point of interaction for various applications. The following list outlines some of the applications that interact with the Service Layer:

   • Job service - Alert and Scheduling
   • Electronic Document Service (EDS)
   • SAP Business One, Web client
   • SAP Business One Integration (B1i) scenarios using Service Layer
   • Mobile service
   • All partner add-ons using Service Layer
2. Requests handled by Service Layer

   Service Layer is dependent on the OBServer for business logic. Processing a request depends on the following factors:

   • The type of requests - (GET/PATCH/DELETE/POST)
   • The complexity of the request
     • The objects used in the request, for example, Documents, Items, Production Order, Picklists, Activity, and Contacts.
     • The number of lines processed in the requests.
     • The number of serial numbers and batch numbers processed.
     • The number of bin locations processed.
   • Total requests - Total number of requests processed by Service Layer.
   • Concurrency - Number of simultaneous requests processed by Service Layer.
3. Impact due to database response

   The database response time strongly influences how the request is processed. The database response time depends on the following factors:

   • The size of the database.
   • The nsumber of rows on the table you are operating.
   • The number of other concurrent processes which could generate database activity. For example, other add-ons, SAP Business One Desktop Client, reports, and alerts.
   • The customization on the database, such as a huge number of UDF, UDT, UDO.
   • Notification logics in notification procedures.

Now that you know more about the Service Layer dependencies, use the following guidelines to help you arrive at a baseline for your Service Layer scenario.

• For easy scaling, it is recommended to install Service Layer on a separate machine to the SLD/database machine. This allows you to avoid the contention for resources with database services and scale easily where required.
• If SAP built applications (Web Client, Job service, EDS) are heavily used, it is recommended to have a separate Service Layer instance for SAP built-in applications.

• The higher the CPU clock speed, the faster the processing time of instruction. Therefore, make sure that you have the best clock speed on the Service Layer server.
• The more CPU core allows, the more parallel processing. In general, the optimal performance is when the number of cores equals the number of Service Layer load balancer members. Having a higher number of cores does not guarantee better performance.
• Faster hard disc and network cards:
  • There are several operations which require writing files on a hard disk for example, login, attachments, and writing logs. A faster disk makes the disk I/O (Input/Output) operations faster.
  • The Service Layer constantly interacts with other SAP Business One services, such as SLD and Authentication service, which requires clean network connectivity.
• The higher RAM size gives you more flexibility with the configurations:
  • In general, there should be less swapping of memory. Consider all applications which will be running on the machine (both SAP and non-SAP). Use the sizing guides where applicable.
  • Memory consumption also depends on the number of load balancer members and the Maximum Threads per Load Balancer Member configuration. It is recommended to reserve at least 1 GB of RAM per Service Layer httpd process on the machine where Service Layer is running.

• It is recommended to regularly restart the Service Layer and System Landscape Directory (SLD) services at least once a day. You can create OS level jobs to perform this task.
• Plan and perform bulk operations when concurrent users are less active or when users are offline. For example, pricelist updates or importing marketing documents using DTW.
• When SAP HANA database schema and Service Layer are running on the same machine, make sure to follow standard backup guidelines. Refer to the SAP Note 1950261.
• Clear unnecessary logs and core dumps regularly. Refer to the SAP Note:2441140 for the log location. Debug or detailed logs consume a lot of disk space. Do not enable any detailed logs or debug logs unless you are investigating an issue.

You can use the Service Layer Controller center to configure Service Layer. The following are some guidelines to help you decide on the configuration values.

Find out how many schemas (for example, 2) and how many concurrent distinct users per schema (for example, 8) the customers have. Then install Service Layer with 2*8=16 load balancer members; the minimum memory needed is 16 GB.

• For Service Layer on SAP HANA, you can specify the Maximum Threads per Load Balancer Member during the installation. This setting generates as many child processes as possible for each load balancer member. For example, Maximum Threads per Load Balancer Member is set to 20 and you have 4 load balancer members. Then, a maximum of 20*4 = 80 child processes can be reached. It can consume up to 80 GB of memory.
• For Service Layer on Windows, you cannot change Maximum Threads per Load Balancer Member during the installation. By default, it is set to 1. Internally, threads are handled by the Windows operating system.
• If the same user makes multiple requests from different applications, then these requests are processed by different nodes. In this case, you’d need more than one thread per node. For example, if a user wants to generate 10 requests asynchronously, then you may need to set the value to 10. Refer to Apache documentation.

• A sticky session allows you to stick with one observer connection and reuse it until it is destroyed. This makes memory management and data usage more efficient. However, effective load balancing is not possible. For resource-intensive operations, it is recommended to enable the sticky session. For a high concurrency scenario, disable the sticky session.
• You can also isolate high resource-intensive requests to separate nodes by setting SPAR nodes. Refer to the SAP Note 3311536.

• This setting limits the number of connections that an individual child server process can handle. Once the limit is reached, the child process closes. Refer to Apache Performance Tuning document. In general, it is recommended to maintain a value of 1024 or more. This means, the child process lives longer. All data loaded for the process is available in the buffer and enables better performance.
• If you have a single machine running all services, and overall RAM allocation is less, you can reduce the value. This means memory is released periodically. However, the initializing time for new processes is longer.

You may use any development language that supports OData operations. The following are some guidelines to consider when making an OData request to Service Layer.

• Only retrieve data that is required for the process and use the techniques that you learned about in Unit 2 of this course, such as:
  • Pagination
  • "return no content"
  • $batch for short multiple transaction
  • Navigation and association
  • User-defined schema
  • ETag for concurrent operation
• The best approach for a web application is to use combination of Synchronous (SYNC) and Asynchronous (ASYNC) calls based on the request type. For example, GET requests are ASYN and all others are SYNC.
• Browsers limit the number of HTTP connections with the same domain name. This restriction is defined in the HTTP specification (RFC 2616). Most modern browsers, such as Google Chrome or Microsoft Edge allow six connections per domain.
• Avoid repeated login and logout logic, and reuse the same sessions.