Helping Support to HELP YOU! (Pipeline Pilot)

During a case interaction between Support and Customers, we all can benefit from a detailed description of the issue. Insufficient case Description, Product, Release, or means to reproduce it, can delay the identification and resolution. This process consume resources at both ends.

As part of the Service Level Agreement (SLA) we describe the level of engagement needed when raising a support request for BIOVIA as well as for the customer. https://www.3ds.com/terms/support-policies/ under the section “For Licensed Programs > How to file a Case?”, we have a comprehensive list of requirements and guidelines needed to start a Support investigation.


When reporting a Pipeline Pilot issue. Support will need the following information:

  • Version affected
  • Full Error Stack messages
  • Server error logs
  • Example or detailed description exposing the reported behaviour.

Version affected:

Pipeline Pilot client

If you are using the Pipeline Pilot client, you can obtain the Pipeline Pilot version from the Help menu > “About Pipeline Pilot

The resulting window compiles the client version, and build date as well as Server version, Server location (URL) and Server OS.

That information is required when filling a case, and help BIOVIA Support to focus our investigation.

Server Home Page

From the Server Home Page you can have information about the version used. On most recent releases, you may need to be signed in to get access to the Server version.

​​​​​​​

Full Error Stack messages

When the error appears as result of a client execution, a warning sign is displayed on the component failing and some additional information on the failure.

​​​​​​​

Selecting “Details >>”, will display the full error stack. In most of the case, the information provided help to address the issue.

​​​​​​​


This text can be copied and pasted as plain text. Attach the resulting text content of the section “Error Stack” to the case report. Avoid, when possible, screenshot of the error message.

Server error logs - Operations

Pipeline Pilot compiles a list of logs files as part of its normal operation. Some of these logs may contain warning or error messages related to the issue raised. The messages folder is located under /logs (/logs/messages), where represents the root folder where the Pipeline Pilot Server is installed. We can greatly benefit from the exact time where the error occurs for correlation.

When communicate with Support you may need to involve your Pipeline Pilot Server administrator to share and include the content of the messages folder as part of the case.

Ideally, we would require full content of the messages folder. The easiest way is to compress the folder and add it to the Support request.


If during the first identification phase full content is not available, at least we will need content of any logs modified during the timeframe the error occurs, indicating the exact time for failure. Insufficient log information may delay the understanding and resolution of the issue reported.

Server error logs - Installation

During the installation or upgrade of Pipeline Pilot, a log file gets created reflecting the installation process. If the issue is related to an installation, please enclose the content of the install folder under /logs (/logs/install), where represents the root folder where the Pipeline Pilot Server is installed.

Additional logs

Each collection may include an additional installation log. If during the installation there is any error against a BIOVIA collection, for example “Chemistry Collection”, the installation log will report it as part of the install logs. In such scenario, navigate to the collection reporting the failure and include, if exists, the log folder. On this example located under /apps/scitegic/chemistry (/apps/scitegic/chemistry/log).

An example of such behaviour may occur when there is a missing dependency required for that collection.

Notice that not all collections build a log at install/uninstall phase.

BIOVIA Support will inspect the logs and will try to correlate with any operation causing a failure.


Deserialized example

Can you create an example exposing the behaviour reported? Can you share it?

If you can present to us a simple protocol or process, where the error is exposed, it can benefit to address the issue. With that information, we can discuss the issue not exposing your data and we both can share an example with a possible solution you can then translated to your specific needs.

Whenever possible a deserialised example on a vanilla environment can help to address the issue.

Notice we may need to present the case to Development for further analysis and if you involve custom code or implementation, our capability of support may be limited when recreating the case before presenting it to Development.