Ir al contenido principal

Error: Your convergence sessions have been closed because of timeout (How to manage timeouts in v7 and higher with Syracuse)


Description
  • Error: "Your convergence sessions have been closed because of timeout" when a session has been idle for more 20 minutes.
  • The Timeout parameters TIMEHGUP1,TIMEHGUP2 and TIMEHGUP3 are already set to 0 for no timeout.
  • How do I set the timeout for Sage X3?
Note: This article only applies to X3 v7 and higher. as time out is handled by a Syracuse setting.
  • TIMEHGUPx settings are no longer used in v7 and higher.  
For X3 v6 and lower, see knowledgebase article 18654 below.


Disclaimer
Backup Warning
Use caution when working with the below product functionality. Always create a backup of your data before proceeding with advanced solutions. If necessary, seek the assistance of a qualified Sage business partner, network administrator, or Sage customer support analyst.
Database Warning
These steps require knowledge of database engines and application databases (DBs) used by your Sage product (including Microsoft/Transact SQL, Pervasive SQL, or MySQL, etc.). Customer Support is not responsible for assisting with these steps and cannot be responsible for errors resulting from changes to the database engine or DBs. Before making changes, backup all system and application DBs required for a full restore. Contact an authorized business partner or DB administrator for assistance.

Cause
This is due to a timeout setting in the nodelocal.js file, used by the Syracuse server.  The default timeout setting for a connection to the Syracuse Web Server is 20 minutes.  
Note: Actual timeout duration may be 3 minutes shorter than what's listed (17 minutes instead of 20).  If users leave sessions opened for longer than this duration, they may see this error.  If this setting is modified incorrectly or users have multiple Syracuse servers and some servers were modified but others were not, users may also see this error at different duration lengths.


Resolution
Note: This article only applies to X3 v7 and higher.  For X3 v6 and lower, see knowledgebase article 18654 below.
  1. Have all users exit Sage X3.
  2. On the Syracuse server, browse to ..\Syracuse\syracuse\bin\ and locate a file called nodelocal.js
  3. Make a copy of the nodelocal.js file.
  4. Once a copy has been made, right-click the nodelocal.js file and select Edit (or open it with Notepad if this option is not available).
  5. Change the timeout value from 20 to the desired duration:
    •  The nodelocal.js file will have a section similar to what's below.  Edit the 20 to something higher, such as 480.  The value 20 represents 20 minutes.  The 20 is two character digits.  Do not exceed more than 5 character digits as doing so may cause problems with Syracuse.
    •  session: {
         timeout: 20,       // minutes
         checkInterval: 60, // seconds
         "auth": "basic"
       },
  6. Save the file.
  7. Restart the Syracuse service.
    • If the Syracuse service does not start or if logging into Sage X3 generates errors, this generally means the nodelocal.js file was edited incorrectly.  Restore the copy and attempt steps in this KB again, making sure not to exceed 5 character digits in the value and no extra characters are added or deleted.
Note:  The timeout is unique to each Web browser tab.  If you are working on the first Web browser tab in X3, and open a second tab and continue to work on the second tab without going back to the first tab, the first Web browser tab will time out.  You will not see the timeout message until you click back on the first tab.

Special considerations for multi-Syracuse servers
If after following all these steps above and you are still seeing wildly different timeout durations, you must then verify if you have multiple Syracuse servers running, and thus different nodelocal.js files with different settings.  To do this:
  1. Have affected users log into X3.  (i.e. users who have the wrong timeouts) 
  2. Have unaffected users log into X3.   (i.e. users who have the correct timeouts)
  3. Log into X3 as an admin who has access to the Administration menu.
  4. Locate the menu item "Web client sessions" and click to open that screen.
  5. Look for a column called Server name.  This is the Syracuse server.  If there are multiple Syracuse servers, you will see the different server names.
  6. Log into the affected server, and perform the steps noted above to change the timeout setting to make it active.
  7. Users must log out of Sage X3 and log back in for changes to take effect.

Known behavior:  Syracuse pages (main navigation pages and menu items under Administration) may time out 5 minutes after the value set in the nodelocal.js file.  This is intentional to allow convergence/classic sessions (any menu item in blocks other than Administration) to safely timeout.

Convergence (classic) sessions will time out 3 minutes sooner than the value set in the nodelocal.js file.  This issue is currently being investigated.

Entradas populares de este blog

SAGE X3 SILENT IMPORT (IMPORTSIL) WITH ERROR CATCHING

FUENTE ORIGINAL: https://pluginx3.com/en/blog/post/sage-x3-silent-import-importsil-with-error-catching.html You already know how to manually generate a CSV file in order to import it threw a template in Sage X3. But If you wonder how to catch detailed errors after a silent import here is the solution. Sometimes you need to catch the incoming errors in order to alert the end-user regarding an issue. Closed period, wrong date etc …. Unfortunalty the standard Sage X3 silent import function doesn’t natively show the detailed errors during the import process. Call IMPORTSIL([M:IMP2]MODIMP,[M:IMP2]NOMIMP) From GIMPOBJ And the standard function ERR_IMPORT will only show the overall status of the importation and not the detailed errors. IMPORTSIL function is pushing all the log data into a tracefile in order to avoid any popup on end-user screen. So you have a log file available in order to search for errors in it. Sage X3 runtime is using the same principals standards as any shell for log...
Leer más

How to Call an External Program from Sage ERP X3

Origen fuente:   https://www.rklesolutions.com/blog/sage-x3-call-external-program November 20, 2014 By Denise Hartman Leave a Comment It is sometimes useful to be able to access external programs, such as .exe files, from the  Sage ERP X3   menu. Below are instructions for adding a menu item to Sage X3 that references a .Net .exe. COPY THE .EXE FILE TO THE SAGE X3 DIRECTORY The example used here uses the  Callui  function in the Sage X3 code to call OpenFile, and references the .exe program using the parameter UILocalDir. The program being executed must reside in a pre-defined list of directories available to this function. Depending on the parameter used for UILocalDir, the .exe should be copied to one of the 3 directories below. Temp Report RtsTemp Below is an excerpt from the X3 Help, which defines where each of these directories resides within the Sage ERP X3 client installation. In this example, the Temp directory is used. Bel...
Leer más

How to Delete particular row and reset Grid

Origen: https://www.greytrix.com/blogs/sagex3/2014/06/30/how-to-delete-particular-row-and-reset-grid/ By  Greytrix   |   June 30, 2014 0 Comment We usually come across a scenario when we need to delete row from a grid through coding. Now we can even think of using SQL queries to delete the data, but these changes were reflected at the database level. The screen do not have the changes reflected and this may cause data inconsistency. So for deleting line from grid and then resetting the grid I used ‘DELA’ an existing function of X3. New Stuff :   How to send mail programmatically Dela  is used to delete elements from single-sized tables, from a given index. And also it resets the grid.   Syntax: Dela start [ , number [ , limit ] ] list_nom_var Example: Dela is used to delete elements (default 1) from a set of single-sized tables. In the instruction’s syntax, start establishes the index (shared by all the tables) where the deletion ...
Leer más