Skip to main content
Do you build apps on Splunk or are a Splunk admin? If so, we want to hear from you. Help shape the future of Splunk and win a $35 gift card!
 
 
Splunk Lantern

EDI: Transmission errors and retry rates

 

This article shows you how to build a search to check for EDI documents that fail to transmit or are stuck in retry loops. This is a key performance indicator for companies that need to monitor electronic data interchange (EDI) transmission and acknowledgement. EDI plays a critical role in ensuring that data flows seamlessly across various stakeholders—suppliers, manufacturers, logistics providers, and retailers—without manual intervention. It is a core technology for automating supply chain processes. By continuously monitoring EDI transmissions and acknowledgments, businesses can proactively identify and resolve issues, ensuring smooth communication between systems and uninterrupted supply chain operations.

KPI search example

Another KPI for monitoring the health of EDI transaction systems is the error and retry rates. Unlike transaction requests that lack an acknowledgment, which may not necessarily indicate an error or failure but rather a delay, errors and retries are more definitive. In this case, we specifically look for requests with acknowledgments marked with E for error and R for retries. This indicates that the receiving system has indeed received the request, but errors or retries occurred on their end. Therefore, these situations require immediate attention to ensure that proper orders are issued to the supply chain teams.

A high error rate or frequent retries can indicate underlying issues with the EDI system, such as incorrect formatting, network problems, or data discrepancies. Consistent errors or retries can delay document processing and disrupt supply chain operations.

To calculate the error and retry rates, similar to calculating the success rate, we need to count the total number of requests along with the number of error and retry requests, and then apply a formula to determine the respective rates. This involves aggregating both the total requests and the error/retry events. Using the timechart command, we can generate a statistical trend with the following SPL. The command search edi_ack_status=E OR edi_ack_status=R will filter for EDI requests that have acknowledgments marked with E (Error) or R (Retry).

index=supply_chain_edi sourcetype="edi:x12"
| eval edi_ack_status_combo=edi_code+"-"+edi_code_ack+"-"+edi_ack_status 
| eval edi_code_groupby=if(isnull(edi_code_ack), edi_code, edi_code_ack) 
| stats last(_time) AS _time, last(edi_requestor) AS edi_requestor, last(edi_responder) AS edi_responder, first(edi_code) AS edi_type, values(edi_code) AS edi_code, last(edi_ack_status) AS edi_ack_status BY edi_tr_id edi_code_groupby
| search edi_ack_status=E OR edi_ack_status=R

image2.png

Similar to calculating the transmission success rate, the error and retry rates can be computed using the eval command by applying a simple ratio formula. To achieve this, we also need to include transactions that have been successfully accepted by applying a search condition, such as | search edi_ack_status=E OR edi_ack_status=R OR edi_ack_status=A, which adds the edi_ack_status=A status. Then, by using the timechart command, we can calculate the trend, followed by the eval command to determine the total transactions and the error_retry_rate to obtain the error and retry rates.

index=supply_chain_edi sourcetype="edi:x12"
| eval edi_ack_status_combo=edi_code+"-"+edi_code_ack+"-"+edi_ack_status 
| eval edi_code_groupby=if(isnull(edi_code_ack), edi_code, edi_code_ack) 
| stats last(_time) AS _time, last(edi_requestor) AS edi_requestor, last(edi_responder) AS edi_responder, first(edi_code) AS edi_type, values(edi_code) ASedi_code, last(edi_ack_status) AS edi_ack_status BY edi_tr_id edi_code_groupby
| search edi_ack_status=E OR edi_ack_status=R OR edi_ack_status=A
| timechart count BY edi_ack_status
| eval total_transactions=A+E+R
| eval error_retry_rate=((E+R)/total_transactions)*100

image17.png

Use a line graph visualization to clearly show the distribution of the different results over time.

image14.png

Search explanations

Splunk search Explanation
index=supply_chain_edi sourcetype="edi:x12" Select EDI X12 data by selecting sourcetype of edi:x12.
| eval edi_ack_status_combo=edi_code+"-"+edi_code_ack+"-"+edi_ack_status
| eval edi_code_groupby=if(isnull(edi_code_ack), edi_code, edi_code_ack)
Create a new evaluated field edi_ack_status_combo that combines edi_codeedi_code_ackedi_ack_statusfield. Use another evalcommand to create edi_code_groupby field to join all EDI events with EDI 997 acknowledgment events.
| stats last(_time) AS _time, last(edi_requestor) AS edi_requestor, last(edi_responder) AS edi_responder, first(edi_code) AS edi_type, values(edi_code) AS edi_code, last(edi_ack_status) AS edi_ack_status BY edi_tr_id edi_code_groupby

Join all EDI events with EDI 997 (acknowledgment) events into a single event. A successfully joined event will have EDI edi_ack_status field that indicates there was a matching pair of EDI with EDI acknowledgment.

Events with null values in edi_ack_status means that there's no matching pair of EDI acknowledgments. Events with successfully joined EDIs have “A”, “E”, “R” flags indicating their status.

| search edi_ack_status=E OR edi_ack_status=R OR edi_ack_status=A Filter to select EDI transactions that have received the responses, either accepted, error status or rejected. This excluded transactions that were still waiting for acknowledgment.
| timechart count BY edi_ack_status Create aggregate statistics of top edi_ack_status, to see the amount of transactions that have received with some status over time.
| eval total_transactions=A+E+R Calculate the total transactions, accepted, error or rejected.
| eval error_retry_rate=((E+R)/total_transactions)*100 With the calculated total, apply a formula to calculate the ratio of transactions that have errors or retries.

Repeated transmission errors or high retry counts might signal problems with the EDI setup or system integration. These issues could lead to incomplete document transfers, inaccurate order fulfillment, or failed communications between partners.

Next steps

When you have this search running in your Splunk platform, return to the Monitoring electronic data interchange transmission and acknowledgement use case to learn how to share the results with stakeholders and to find other KPIs you might want to measure. You can also review the Solution Accelerator for Supply Chain Optimization for more great use cases to help you use the Splunk platform to be successful in your supply chain operations.