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

Valores de fstat

Fstat fstat  is a numeric status that is returned upon execution of a database operation, a sequential file operation, or a lock instruction. Syntax fstat Examples # MYTABLE is a table with a key called KEY1, that has a unique component called KEYVAL # Create a record in the table MYTABLE with they key value 1 if it doesn't exist Local File MYTABLE [MYT] Read [MYT]KEY1=1 If fstat [MYT]KEYVAL=1 : Write [MYT] If fstat MSG="The key was created in the mean time" Else MSG="Key created" Endif Else MSG="Key already exists" Endif Details fstat  is always set to '0' if the operation is successfully completed, and has a non-null value if there is an error: In a sequential read ( Getseq  and  Rdseq ),  fstat  is set to '1' at the end of the file. On  Lock ,  fstat  is set to '1' if the lock could not be performed. For a database operation ( Read ,  Look ,  Readlock ,  For ,  Write ,  ...
Leer más

How To Add a Custom Selector for the Screen Field

Fuente original del artículo:   https://www.rklesolutions.com/blog/how-to-add-a-custom-selector-for-the-screen-field January 5, 2022 By RKL Team Leave a Comment There may be times when you want to add a pop-up window to select a field for a screen. Sometimes this can be handled automatically if the field is a standard X3 object field (i.e. when selecting a product with a type of ITM from the ITMMASTER table). There may be other times where a standard look-up is not available, and some custom code is required to do the selection window. We'll show you how to add a custom selector of your choosing to the screen field. ADD SELECT ON SCREEN FIELD The first step is to add the appropriate code to the field on the screen in Sage X3: Go to  Development > Script Dictionary > Screens Select Your Screen Select the field to have the lookup for  by moving your cursor to it on the screen. The field should show with a blue background. Select a type of "Selection" , and an  ac...
Leer más