OData API for material management returns slow response times during bulk material creation

ERP SAP S/4HANA
, , , , , , , ,
1

We’re experiencing significant performance degradation when creating materials in bulk via the OData API (I_ProductTP service). Creating 500 materials takes over 45 minutes, which is unacceptable for our daily integration jobs.

Current implementation sends individual POST requests:


POST /sap/opu/odata/sap/API_PRODUCT_SRV/A_Product
Content-Type: application/json
{
  "Product": "MAT-12345",
  "ProductType": "FERT"
}

The batch processing strategy doesn’t seem optimal, and I suspect the underlying CDS views might be contributing to the delay. We’re on S/4HANA 2020 FPS02. Has anyone dealt with bulk material creation performance issues? What’s the recommended approach for optimizing OData batch operations when dealing with large volumes?

2

Individual POST requests are definitely your bottleneck. You should be using OData batch requests with the $batch endpoint. This allows you to bundle multiple operations into a single HTTP request, drastically reducing network overhead and connection time. The API_PRODUCT_SRV supports batch operations natively.

3

Let me provide a comprehensive solution addressing all three optimization areas:

1. Bulk Operation Optimization Implement OData $batch with optimal sizing:


POST /sap/opu/odata/sap/API_PRODUCT_SRV/$batch
Content-Type: multipart/mixed; boundary=batch_001

--batch_001
Content-Type: application/http

POST A_Product HTTP/1.1
{"Product": "MAT-001", "ProductType": "FERT"}

Use 50-75 materials per batch request. This balances transaction size with commit frequency. Larger batches risk timeouts and make error recovery harder.

2. CDS View Performance The I_ProductTP view is comprehensive but heavy. Use a staged approach:

  • Stage 1: Create basic material (Product, ProductType, BaseUnit) via I_ProductTP
  • Stage 2: Extend to plants using I_ProductPlantBasic
  • Stage 3: Add sales org data via I_ProductSalesDelivery

This prevents the CDS view from joining 15+ tables during initial creation. Our benchmarks show 60% improvement with staged creation.

3. Batch Processing Strategy Implement parallel processing with proper error handling:

  • Split your 500 materials into 10 batches of 50
  • Process 2-3 batches in parallel (test your system’s capacity)
  • Implement retry logic for failed batches
  • Log each batch result separately for troubleshooting

Additional optimizations:

  • Disable number range buffering check (SNUM_BUFFERING) if using external numbering
  • Schedule during off-peak hours to avoid lock contention
  • Monitor table MARA locks using SM12 during processing
  • Consider using background job processing (transaction SM37) instead of real-time API calls for very large volumes

With these changes, you should achieve sub-10 minute processing for 500 materials. I’ve implemented this pattern across 4 S/4HANA implementations with consistent results. The key is reducing the CDS view complexity per operation and optimizing batch sizes based on your specific system capacity.

4

Another factor: check if custom BAdIs or user exits are active in your material creation process. Use transaction SE19 to review active BAdI implementations for material master. We discovered a custom validation BAdI that was making database calls for each material, adding 3-4 seconds per record. Disabling it during bulk loads and running validation separately reduced our total time significantly.

5

Thanks for the suggestions. I implemented batch requests but still seeing around 25 minutes for 500 materials. The CDS view optimization point is interesting - we are including plant data and sales org assignments in the initial POST. Would it be better to use a two-stage approach?