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

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 create an additional line text (ACLOB) on purchase orders for internal notes

Sin conexión Kyle Klinger hace 1 día Origen:  https://www.sagecity.com/support_communities/sage_erp_x3/f/sage-x3-general-discussion-forum/143870/how-to-create-an-additional-line-text-aclob-on-purchase-orders-for-internal-notes I was trying to add internal notes to the purchase orders at a line level and was thought I would share a how to.  If you have a better way, please share.     Add column to PORDERQ; YLINTEX2, Type TXC   Save and validate table This is where the ID of the text will be stored at the record level, i.e. POQ~00000007, this is similar to field LINTEX  On screen POH2 Add column YLINTEX2, to Block 1. Most likely you will want this field to be hidden. On column NBLIG add a button action ACLOB2, description "Text internal" This button action will require an action parameter "CODE2", it will not be available until after save. Set the parameter "CODE2" to [M:POH2]YLINTEX2(nolign-2), the field that was just added....
Leer más

3 ways to send a mail from code in Sage X3, with more attachments too

Origen Fuente:  https://en.sagedev.it/sagex3/send-mail-from-code-with-attachments-sage-x3/ Autor:  https://en.sagedev.it/category/sagex3/ In this post I’ll show you how to send a mail from adonix code in Sage X3. The points we will face are: 1) Meladx/Send introduction 2) Sending  through  meladx (the best way for me: at the end with just a single code line you send a mail!) 3) Sending  through  Workflow 4) Sending  through  ENVOI_MAIL(…) From AWRKMEL Sending mail from code in Sage X3: Send vs meladx Sage X3 has two native ways for sending mails. The first way is  meladx  executable file, that you can find in  runtime\bin  directory. The seconde one is Send instruction, that was used to send mail through an application of the client station (for more information on “Send GSERMES”  go here ). The Meladx executable Meladx send messages through SMTP/POP3 protocols by means of the mail  ...
Leer más