Troubleshooting practice questions

The Content Modifier step must be configured with 'Overwrite' enabled for headers to be visible to downstream steps.

Why it fails: The Overwrite option controls what happens when a header or property with the same name already exists; it does not determine visibility. Even without Overwrite, a newly created header is visible downstream, so this setting cannot be the root cause of the routing failure.

The Router step evaluates XPath against the payload, not against headers, so referencing a header in the XPath expression always fails.

Why it fails: The Router step can evaluate expressions against headers, properties, or the body depending on the expression type selected. Saying XPath can never reference headers is technically incorrect, and the real issue is likely the expression type chosen rather than the inability to read headers at all.

The Router step requires the header name to be prefixed with 'SAP_' to be visible to the routing expression.

Why it fails: There is no such prefix requirement for custom headers in SAP Cloud Integration routing expressions. Headers created by a Content Modifier are visible under their exact configured name, so inventing a reserved prefix does not explain the observed default-branch behaviour.

The mapping step requires the message body to be converted to XML before processing JSON.

Why it fails: SAP Cloud Integration mapping steps can work with JSON directly if the message's Content-Type is set to application/json. There is no requirement to convert to XML first. The failure is likely because the Content-Type header is not correctly indicating JSON, so the mapping step treats it as plain text or XML.

The Request Reply step does not support JSON responses and only handles XML.

Why it fails: The Request Reply step in SAP Cloud Integration is protocol-agnostic and can handle any payload type, including JSON. It simply sends the request and receives the response. The issue is not a limitation of the step itself but rather how the response's content type is handled downstream.

The Content Modifier step must also set the 'Accept' header to 'application/json' to receive a JSON response.

Why it fails: While setting the 'Accept' header is good practice to indicate the desired response format, the absence of it does not prevent the API from returning JSON if that is its default. The problem described is that the mapping step fails to recognize the JSON, which is more likely due to the response's Content-Type not being set correctly, not the request's Accept header.

Use the message.getBody(InputStream.class) method and read the stream without null checks.

Why it fails: Reading the stream without null checks would still result in a NullPointerException if the body is empty, because the InputStream would be null. This approach does not handle the empty body scenario and would cause the flow to fail. It is not a robust solution for the requirement.

Configure a Content Modifier step before the script to set a default body if empty.

Why it fails: A Content Modifier step cannot conditionally set a default body based on emptiness without complex expressions. While it can set a body, it does not easily check for null. This approach adds unnecessary complexity and may not reliably handle the empty body case, making it less suitable than handling it directly in the script.

Wrap the property assignment in a try-catch block and ignore the exception.

Why it fails: Wrapping in try-catch and ignoring the exception would prevent the flow from failing, but it would not set the property to a default value. The property would remain unset, potentially causing downstream errors. This approach does not meet the requirement of ensuring a default value is assigned when the body is empty.

The producer integration flow is using a different JMS connection alias than the consumer

Why it fails: Different JMS connection aliases can point to different JMS brokers or configurations, which could cause messages to be placed in a queue not visible to the consumer. However, the scenario states the queue name matches and messages are accumulating, implying they are in the same queue. If aliases differed, the producer would typically fail or write elsewhere, not accumulate in the observed queue.

The JMS queue was created with a maximum message size that is too small for the payloads

Why it fails: A maximum message size limit would cause individual messages to be rejected at production time, not accumulate silently in the queue. The scenario states messages are accumulating, meaning they were successfully enqueued. Therefore, a size limit is not the cause of the consumption problem, and changing it would not resolve the unconsumed messages.

The consumer integration flow is deployed but its timer or sender trigger is disabled

Why it fails: A JMS receiver adapter in a separate integration flow is itself the trigger; it polls the queue when the flow is deployed and running. There is no separate timer needed for a JMS-triggered flow. If the flow is deployed and running as stated, the JMS receiver should poll automatically, so a disabled trigger is not consistent with the described state.

The Poll Interval configured on the SFTP sender channel

Why it fails: The Poll Interval only controls how frequently the adapter checks the directory for new files. Shortening or lengthening it changes detection latency but does not by itself guarantee that an already-consumed file is excluded from a later poll, so it does not address the root cause of duplicate processing.

The file name pattern restriction, for example limiting reads to files ending in .done

Why it fails: A filename pattern narrows which files the adapter considers, which is useful for ignoring temporary files, but it does not track what has already been processed. Once the file is renamed to its final name, the pattern still matches it on every poll, so duplicates remain possible unless consumption tracking is configured.

The Maximum Reconnect Attempts and Retry Interval values on the SFTP channel

Why it fails: Reconnect and retry settings govern how the adapter recovers from network or authentication failures when opening the SFTP session. They influence resilience of the connection, not whether a file that was already read successfully is read again, so tuning them will not stop the duplication observed in this flow.

Switch the receiver adapter to the SOAP protocol to reduce overhead

Why it fails: Changing the protocol does not address backend processing time and would require rebuilding the request and response handling for a different interface contract. The S/4HANA service being called is exposed as OData, so a SOAP call would not map to the same endpoint and would likely fail outright.

Move the OData call into a Local Integration Process to isolate it

Why it fails: A Local Integration Process is a structural construct for reusing or organizing flow logic, not a resilience mechanism. It does not alter timeout behavior, retry behavior, or backend load, so moving the call there leaves the intermittent timeout condition unchanged.

Disable the CSRF token handling in the adapter to save a round trip

Why it fails: CSRF token handling is required for write operations against S/4HANA OData services. Disabling it would cause the backend to reject the modifying requests with a security error, replacing intermittent timeouts with consistent authorization failures, so it worsens rather than improves resilience.

The Groovy script is trying to access the header using the wrong API method, such as getHeader instead of getProperty.

Why it fails: Using getHeader is correct for headers; getProperty is for exchange properties. The NullPointerException suggests the header is not present, not that the method is wrong. If the method were wrong, it might return null but not necessarily throw an exception immediately.

The Content Modifier step is configured to set the header only in the 'Expression' mode, and the expression evaluates to null.

Why it fails: If the expression evaluates to null, the header may be set to null or not set. However, the NullPointerException occurs when accessing the header, implying the header itself is missing. This could be a cause, but it's less likely than a scope issue.

The header name 'CustomerID' is case-sensitive and the Content Modifier set it as 'customerid'.

Why it fails: Header names in SAP Cloud Integration are case-sensitive, but if the Content Modifier set it with different casing, the script would not find it. However, this would typically result in a null value, not necessarily a NullPointerException unless the script calls a method on the null header. It's a possible cause but less likely than a scope issue.

The 'Timeout' value is set too low, causing the request to fail before authentication.

Why it fails: A low timeout would result in a timeout error, not a 401 Unauthorized. A 401 indicates that the request reached the server but lacked valid authentication. Timeout settings affect how long the client waits for a response, not whether credentials are sent. So this is not the cause.

The 'Proxy Type' is set to 'Internet' instead of 'On-Premise'.

Why it fails: The proxy type determines the network route (Internet vs. on-premise via Cloud Connector). If the API is on the internet, 'Internet' is correct. If it were on-premise, 'On-Premise' would be needed. A wrong proxy type would typically cause a connection error, not a 401. Authentication is independent of proxy type.

The 'CSRF Protected' checkbox is enabled.

Why it fails: The 'CSRF Protected' option is used for SAP-specific CSRF token handling, not for standard authentication. Enabling it would not cause a 401 error; it might add an additional token fetch. However, for a generic REST API, this option should typically be disabled. It is not the cause of a 401 if credentials are correct.

Content Modifier that sets a property based on the fault code.

Why it fails: A Content Modifier cannot catch exceptions. It only modifies the message content or headers. If a fault occurs, the flow fails before the Content Modifier can execute. Thus, it cannot be used for error handling. The Exception Subprocess is the correct step for catching faults.

Router step with a condition on the SOAP fault code.

Why it fails: A Router step evaluates conditions on the message content but does not catch exceptions. If the Request Reply step throws a fault, the message flow is interrupted and the Router step is not reached. Therefore, a Router cannot handle faults; it only routes successful messages. The Exception Subprocess is required to catch errors.

Message Mapping with a conditional expression using the fault code.

Why it fails: Message Mapping transforms the payload but does not handle exceptions. It cannot catch a SOAP fault; if the fault occurs, the mapping step may not even be reached. Error handling must be done in an Exception Subprocess. The mapping cannot route the message to an error subprocess.

Use the removeContexts function on the Items node and map the value to the target total field.

Why it fails: removeContexts clears the context of a node so it can be used in a broader scope, but it does not sum values. Mapping a cleared-context node to the target would produce a single value taken from one occurrence rather than an aggregate of all 500 entries. The function is a scoping tool, not an arithmetic aggregation function.

Use a one-to-many mapping with a context change on the Items node.

Why it fails: A context change resets the queue and is used to control how repeating nodes are grouped, but it does not by itself compute a sum. One-to-many mapping is used to create multiple target nodes from a single source node, which is the opposite of aggregating many source nodes into one target value. Applying it here would still yield per-item output, not a single total.

Use the sort function on the Items node and map the first occurrence to the target total field.

Why it fails: Sorting reorders the repeating entries but does not combine their values. Mapping the first occurrence after sorting yields only one item's amount, not the total across all entries. This would produce an incorrect total and is unrelated to aggregation, so it fails the requirement even though the mapping would execute without error.

The Multicast step was configured with Parallel Processing and the branches share the same message exchange, so an exception in one branch causes the whole exchange to fail.

Why it fails: Parallel Processing changes execution order and thread usage but does not by itself make one branch's failure roll back the other. The branches still operate on separate copies of the message. The observed rollback behavior points to a different configuration issue, such as error handling or transaction scope, not merely to parallel execution.

The SFTP receiver adapter is configured with `Use Temporary File`, so the file is written only after the SOAP branch completes successfully.

Why it fails: `Use Temporary File` affects how the SFTP adapter writes a file, typically renaming a temporary file after a successful write. It does not coordinate with a separate SOAP branch or cause rollback based on that branch's outcome. The described cross-branch rollback is a transaction and error-handling concern, not an SFTP adapter file-writing option.

The Multicast step is missing the `Stop on Exception` setting, so the SFTP branch is aborted when the SOAP branch throws an error.

Why it fails: `Stop on Exception` controls whether the multicast stops other branches when an exception occurs. If it were enabled, the SFTP branch could be skipped, but the symptom described is rollback of an already-executed branch, not skipping. The setting is relevant to branch continuation, not to transactional rollback of a completed SFTP write.

Use message.getHeaders().get('CustomerID').toString() and assign the result to the body

Why it fails: Calling toString() on a null value throws a NullPointerException immediately. This approach does not handle the missing header case; it actually guarantees the exception when the header is absent. The developer must check for null before calling any method on the retrieved value, so this does not resolve the issue.

Use message.getHeader('CustomerID') and assign the result to the body without further processing

Why it fails: The Message interface in SAP Cloud Integration does not provide a getHeader method; headers are accessed through getHeaders(). Using a non-existent method would cause a compilation or runtime error. Even if a similar method existed, assigning without a null check would not handle the absent header case and could still result in a NullPointerException.

Use message.getHeaders().get('CustomerID') and assign the result directly to the body without a null check

Why it fails: Directly assigning the result of get('CustomerID') to the body does not handle the null case. If the header is absent, the value is null and any subsequent operation on it, or the body assignment itself in some contexts, can trigger a NullPointerException. The script must explicitly check for null or provide a default value to avoid the exception.

Enable the 'Use Keep-Alive' option in the HTTP receiver adapter

Why it fails: Keep-Alive allows connections to be reused, which can improve performance, but if the pool is already exhausted, enabling Keep-Alive does not increase the number of available connections. It may help reduce the rate of new connection creation, but it does not solve the immediate exhaustion when many concurrent requests are in flight.

Increase the connection timeout value in the HTTP receiver adapter

Why it fails: Increasing the connection timeout may help if the issue is that connections are timing out while waiting to be established, but the error indicates the pool is exhausted. A longer timeout would not create more connections; it would only make the flow wait longer, potentially worsening the exhaustion. The root cause is likely too many concurrent requests relative to the pool size.

Reduce the number of concurrent threads processing messages in the integration flow

Why it fails: Reducing concurrency would lower the demand for connections, but it would also reduce throughput and may not be acceptable. The error is caused by insufficient pool size relative to the load; reducing load is a workaround, not a fix. The better solution is to increase the pool size to handle the legitimate concurrent requests.

Switch the receiver adapter from HTTPS to HTTP to bypass rate limiting.

Why it fails: Switching from HTTPS to HTTP does not affect rate limiting; the external API enforces limits based on the caller identity and request rate, not the transport protocol. Using HTTP would also reduce security and is not a valid solution. This action fails to address the root cause and introduces additional risk without resolving the 429 errors.

Increase the JVM heap size of the tenant to handle more concurrent requests.

Why it fails: Increasing heap size addresses memory pressure, not rate limiting. HTTP 429 is returned by the external API when the caller exceeds its allowed request rate, so more memory on the tenant does not reduce the number of calls or make the external API accept them. This action does not resolve the root cause and is not a valid resilience measure for rate limiting.

Disable the CSRF protection on the sender adapter to reduce processing overhead.

Why it fails: CSRF protection is relevant to inbound sender adapters, not outbound calls to an external API. Disabling it would not influence the external API's rate limiting behavior. This action is unrelated to the scenario and does not improve resilience against HTTP 429 responses. It may also weaken security for inbound requests, making it an inappropriate choice.

Add a Content Modifier step to remove the `MustUnderstand` header from the response.

Why it fails: The fault is generated by the receiver because it does not understand a header in the request; removing it from the response is too late. A Content Modifier cannot prevent the fault, and the SOAP receiver channel setting is the correct place to control fault behavior.

Set the SOAP version to SOAP 1.2 and enable the `MustUnderstand` attribute on all headers.

Why it fails: Enabling `MustUnderstand` on outgoing headers increases the chance of faults rather than handling them. The issue is an incoming fault from the receiver, so this setting does not address graceful error handling and would likely worsen the problem.

Enable the 'Throw Exception on SOAP Fault' option so the flow fails and can be retried.

Why it fails: Enabling this option causes the flow to fail on a SOAP fault, which is the opposite of routing to an error handling subprocess. The requirement is graceful handling, so throwing an exception would not achieve the desired behavior.