Verifying the Content Services GraphQL deployment
You can validate the Content Services GraphQL deployment for a traditional WebSphere® Application Server environment by accessing the CSGQL Ping Page.
Before you begin
- (Cluster only) Synchronize the nodes.
- Stop the servers.
- Stop the nodes.
- Stop the deployment manager.
- Start the deployment manager.
- Start the nodes.
- Start the servers.
About this task
{
"Build-Date" : "May 04, 2021 at 09:21",
"Implementation-Title" : "IBM FileNet Content Services GraphQL API - content-graphql-api",
"Implementation-Version" : "20210504-1402-605-Administrator",
"Product-Version" : "5.5.8",
"Build-Number" : "605",
"CPE-Client-Jace-Version" : "content-engine-5.5.8-0-143"
}
You can verify the Product-Version, Build-Number, and the CPE-Client-Jace-Version details.
If you are not able to access the CSGQL Ping Page, ensure the deployment and context root values match with the CSGQL application in traditional WebSphere Application Server. You can also check whether the content-graphql-api.war file was started successfully by checking log information from SystemOut.log in traditional WebSphere Application Server CSGQL instance.
If you notice
"CPE-Client-Jace-Version": "Unknown"
in the ping response, it is because of an
issue with the shared library deployment. Make sure that you run the Configuring Shared
Library task (for standalone) successfully and then run the Deploy Instances using the
Graphical User Interface task again.
You can test the CSGQL API functionality with the help of the GraphiQL user interface. The GraphIQL user interface can be accessed from http://server:port/content-services/ where, server is the hostname, and port is the port number for the deployed CSGQL application. The GraphIQL user interface can be accessed only if you enable GraphIQL setting in the Deploy Instances using the Graphical User Interface task.
{
_apiInfo(repositoryIdentifier:“OS1”)
{
buildDate
implementationVersion
buildNumber
productVersion
implementationTitle
cpeInfo {
cpeURL
cpeUser
repositoryName
}
}
}
where, cpeURL is the Content Platform Engine
connection URL details specified in the Deploy Application task, cpeUser is the
Content Platform Engine LDAP user details, and
repositoryName is the object store name.{
"data": {
"_apiInfo": {
"buildDate" : "May 04, 2021 at 09:21",
"implementationVersion" : "20210504-1402-605-Administrator",
"buildNumber" : "605",
"productVersion" : "5.5.8",
"implementationTitle" : "IBM FileNet Content Services GraphQL API - content-graphql-api",
"cpeInfo" : {
"cpeURL" : "http://server.example.com:port/wsi/FNCEWS40MTOM/",
"cpeUser" : "CN=P8Admin,CN=Users,DC=acceadmin,DC=net",
"repositoryName" : "OS1"
}
}
}
}
- Debug
- If the output contains "cpeInfo":null, then the connection between CSGQL
and Content Platform Engine has an issue.
- Verify the Content Platform Engine information and check if the Test Content Platform Engine Connection works in the Deploying instances by using the graphical user interface task.
- Verify the LTPA configuration between the Content Platform Engine and CSGQL.
- Trace flags
- You can set the following trace flags in CSGQL traditional WebSphere Application
Server instance to trace the GraphQL system.
-
- Manually set trace flags by using the traditional WebSphere Application Server administrative interface
-
- Open the WebSphere Application Server Integrated Solutions Console for the CSGQL application instance.
- Expand Troubleshooting and select Logs and trace.
- Select the server where you want to enable traces, and then select Diagnostic Trace.
- Click the Runtime tab.
- Click Change Log Detail Levels. Enter *=info:com.ibm.ecm.content.graphql.*=all in the text box.
- To trace LTPA token issues, add com.ibm.ws.security.ltpa.LTPAToken2=all.
- Check Enable log and trace Correlation and select Include request IDs in log and trace records.
Note: Do not enable the mentioned trace flags in production environment.
-