Web Services Issues

Issue	Cause	Diagnosis	Resolution
Index out of bounds while calling a webservice during runtime.	Sometimes, the ID required for the API call is not retrieved or passed correctly from the source. This inconsistency leads to unexpected behavior such as index out of bounds errors during runtime when accessing elements that do not exist.	Check the source code or configuration where the webservice call is initiated. Review the source layout to ensure that all necessary parameters, including the ID required for the API call, are correctly passed. Verify if the ID is being retrieved and utilized correctly within the webservice call.	Correct Source Implementation: Ensure that the source code or configuration responsible for initiating the webservice call correctly retrieves and passes the required ID. Error Handling and Validation: Implement error handling mechanisms to validate the presence and validity of the ID before making the web service call. Logging and Debugging: Use logging and debugging tools to track the flow of data and identify any discrepancies in the ID retrieval process.
Whenever a request is received from a client or if the client hits the SOAP Provider, the system throws a SOAP fault exception stating that the creation time is ahead of the current time.	This issue occurs when the clock of the machine (where the client hits the service) is not in sync with the clock on the client's machine.	The error logs show a severe validation issue related to the timestamp: com.sun.xml.wss.impl.misc.DefaultSecurityEnvironmentImpl validateTimestamp SEVERE: WSS0229: Exception occurred in validating Timestamp com.sun.xml.wss.impl.callback.TimestampValidationCallback$TimestampValidationException: The creation time is ahead of the current time. at com.adeptia.indigo.services.webservice.metro.JaxWsSecurityHandlerProvider.validateCreationTime(JaxWsSecurityHandlerProvider.java:631) at com.adeptia.indigo.services.webservice.metro.JaxWsSecurityHandlerProvider$DefaultTimestampValidator.validate(JaxWsSecurityHandlerProvider.java:580) This indicates that the timestamps in the SOAP requests are not aligning due to time discrepancies between the machines involved.	Ensure that the machine clocks on both the client side and the server side (where the client hits the services) are synchronized. Additionally, you need to change the SecurityEnvironmentHandler in the request to accommodate the synchronized time settings.
Using SSL to access webservice providers. When we try to access the Adeptia server, the attempt fails.	The error is thrown when the SSL certificate being used is non-existent or invalid.	javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated This indicates that the SSL handshake failed because the server's identity could not be verified, likely due to a missing or invalid SSL certificate.	Verify that a security policy has been selected for the webservice provider and that the SSL certificate is valid. Ensure the client's trust store includes the server's certificate or the certificate authority (CA) that signed the server's certificate. Restart the relevant services after updating or installing the certificate.
All Rest providers are failing java.lang.RuntimeException: The resource Cache Cache is not alive (STATUS_SHUTDOWN): Error while adding object in application cache. [Cache Name=resourceCache]	there is custom plugin which do not have proper finally block to handle the cache and open connection	Check the runtime and Webrunner pod logs for detailed error	In the custom Workflow , there is custom plugin which do not have proper finally block to handle the cache and open connection. After making changes in custom plugin , issue has resolved.