Analyzing the log files from OpenText Content Web Services

Shameer

Kindly checking if anyone could please give some guidance on how to analyze the cws log files, when using Opentext Content Server's CWS(Content Web Services).

Currently in our organization, we have OTCS integrated with a Dot Net based system, using Content Web Services. However, from time to time, the cws log files show different types of errors. Is there any guide available to analyze the log contents, or a log definition dictionary?

I would really appreciate it if anyone could provide some advice on this.

Jacopo

Hi Shameer,

There is nothing more than the available CWS documentation. Error messages might be related to the CWS layer or even surfing up from the underlying OScript layer.

What are the errors you see in the logs?

Shameer

error.txt

Hi Jacopo,

Please find the attached file

Andrea_AC

Hi Shameer,

The errors you've mentioned in the attached files are typically associated with specific libraries used in OScript. The first error (missing file) seems to be related to DAPI, while the second one (incorrect query) appears to be a CAPI issue. I don't believe there's an official direct mapping of these error codes to more specific explanations. Instead, you should investigate what actually happened by checking the other log files. For instance, the CAPI error is likely well-documented in the Connect logs, provided they are enabled.

Andrea_AC

Hi Shameer,
Building on my previous response, it's unfortunately quite common for CWS to show generic error messages. This happens because CWS often functions as a proxy, passing along low-level errors from underlying layers like OScript without adding any additional context. This can make troubleshooting difficult, as the errors might not provide enough information to diagnose the root cause.

In our work with the Module Suite, we've encountered similar challenges. To address this, we've developed custom APIs that include enhanced error handling. Instead of simply passing through these low-level errors, we interpret them and generate more informative, user-friendly messages. This approach not only makes troubleshooting easier but also improves the overall reliability of integrations with the Content Server.

If you're facing recurring issues, it might be worth considering a similar solution. Our experience with the Module Suite has shown that customizing and enriching error messages can significantly reduce the time spent on troubleshooting and improve system stability. If you're interested, we could discuss how such an implementation might benefit your specific case.

Let me know if you need more information or would like to explore this further!

Best regards,
Andrea