Hi Johan,

Maybe the Windows GUI deployment contains a custom DLL which is not available for our Web GUI?

Notice that some of the custom made tasks JPDS is using are only developed to work with our Windows client.

Please let me know whether this answers your question.

Regards Erik

Hi Erik,

I don't think that it is only for the Windows GUI, because it works fine in the web GUI 2019.2.17.

Alright, maybe check the existence of the JPDS specific DLLs in the Projects folder of the Web GUI deployment?

Hi Erik,

I forgot all about this issue until today when I had the same problem again. Sorry about that!

On the web server I check if all DLL's are there and I think that is the case:

A process flow links a task op type “GUI code” to the process. This task is TSFReportMailer. I think this is what fails. How do I know if TSFReportMailer is available in what DLL??

I wouldn't expect the TSFReportMailer to throw up an message like this, because it is included in the DLLs of the GUI itself.

Except the "WaitForResult” field of the report in the SF is configured to "No” or "Yes”. This is a custom task developed by Thinkwise, but not ready yet to report progress back to the GUI.

Any other custom task in this processflow which is possibly missing or only available when working in our Windows GUI?

Regards,

Erik

All reports are configurerd to “Await result = Yes (no progressbar)”. I don't think that any other task is missing. Already in the second step of the process flow the PDF should be created, but it is not.

What else can I do? No debug or process monitor in the web GUI. I really need help with this!

For the web GUI you could log the statements displayed in the debug dialog of our Windows GUI.

Add these two ini parameters to settings.ini:

• LogToFile = yes
• CSVLogging = yes
• ExecutionMode = developer

Also a create a “Logs" directory in the root of the Web GUI directory and assign write rights to it for the IIS pool Identity.

Please do not keep this logging enabled in a production environment for a longer period of time.

Did you check your Tasks in the SF too for the “Await result” setting?

If you do not find a solution to this, please report a TCP issue including a description for reproduction. We also need access to the environment where it occurs. It's also fine to send us a little sample project with the problem in it.

Hi Johan, did you manage to solve this problem or do you still need help?

Hi Jasper. Yes I still do need help with this problem! I saw the log files, but can not find anything related to this problem. Can you help me out here?

Hi Johan,

We need more information about your environment to help you to resolve this problem.

How is the processflow configured? What tasks/reports are involved and what is there configuration? 

You could use the logging to check which database calls are executed already before the error occurs, to check the progress in the executing processflow. Also the "Processflow” tab in the ribbon will provide you information about that.

I'm even thinking about a teamviewer session or maybe we could get access to your environment by VPN?

Please contact me directly by mail to send over confidential information or to plan a session.

Regards,

Erik

Resolved the problem via a teamviewer session.

Points out some of the tasks in the SF of type "GUI code” were configured as Await result = "Yes” which causes the task caller to use an interface which is able to send progress messages back to the shown progress dialog in the client.

Our TSFReportMailer and most of the customer custom written tasks in C# are not ready yet to do so, resulting in this error message.
 

We put Await result to "Yes (without progress)”, which shows only a wait cursor while executing.