[Migrated from the Syclo Resource Center]
Ankur Malhotra 05/03/2011 13:09,
Hi All,This is how I understand Background Sending works: The Agentry Client must initiate a connection (like when the user starts his work days and syncs ,manually,
for the first time), and if the 'Stay Logged in the Server' is true, it remains logged in the Server and so all the transaction he performs are send back, in Background, to the backend.If the user loses the connection in between for say, 15-20 minutes, the Server tries to keep alive the connection for a certain period of time, defined in Agentry.ini, and if the user is back in the network within that predefined time, the connection with the Server remains maintained and Background Sending keeps on working.Kindly correct me if I understood it the wrong way.I have two questions:Can we enable Background Syncing, without the user initiating
a first manual sync (In my experience sometimes it needed two manual syncs to set up the connection with the server required for background syncing)? Like when the user starts his new work day and logs in the device to start his remaining work orders from previous days, without doing
a manual sync?The second question is simply if I have understood the keep alive timing in Agentry.ini correctly. So if the user logs off or is not in network coverage within that keepalive time period, the server keeps trying to maintain that connection.Also I have one more question:In the Application Security Settings, Under User Settings, we have a check box for:Always connect to server from login dialog.Can this connect/transmit be in background? And is it basically designed to do online authentication? It doesn't refresh the client data I suppose.
Regards,Ankur Malhotra
Jason Micklevitz 05/03/2011 15:17
There are a few questions here, so let me take them one at a time. Also, see the following links for details on some of the items involved in the behaviors you are asking about:Transmit ConfigurationTransmit Action Step
First, background sending behavior:The primary purpose of Background sending is to automatically send transactions from the Agentry Client as soon as they are applied to the Agentry Server to be processed, i.e. to update the back end system with the data captured in that transaction.Both background sending an Server Push functionality require a transmit configuration to be configured to keep the user logged into the Server after a standard transmit completes. The user must select this transmit configuration on the client at the beginning of the transmit from the login dialog; or, the Transmit step executed by the action must specify this transmit configuration as the one to use.Once a connection has been made between the Agentry Client and Server and that connection remains open after the standard transmit processing occurs, the network connection will remain open between the Client and Server, the user will remain logged into the Server, and the Client will remain in an On-Line state. All three of these conditions must be true in order for Background sending to function (as well as Sever Push functionality if configured).If the network connection is lost between the Client and Server, the user will remain logged in to the Server for a period of time. The Client will remain in an on-line state. From the Server's standpoint, keeping the user logged in means that if the network connection is reestablished, the full transmit will not be needed to continue the on-line processing. The timeout you mention is the maximum amount of time the Agentry Server will keep a user logged in after the network connection has been lost. After this time period, the user will be logged out of the Server and will be required to perform a full transmit again before resuming either background sending or Server Push functionality.Related to this behavior, if the Agentry Client is unable to send a pending transaction to the Agentry Server using background sending, it will retry sending it based on the definition of the transmit configuration. If the maximum number of allowed attempts is exceeded, the Agentry Client will go from an On-Line state to an Off-Line state. When in an Off-Line state, the Agentry Client will not remain connected to the Agentry Server during any subsequent transmits regardless of the transmit configuration used. The user can change the Client's state back to On-Line by selecting the menu item Off-Line | Work On-Line. This will prompt the user to perform a transmit using the transmit configuration defined to support the real-time communications functionality.Second, background sending cannot be initiated with first performing a transmit from the Agentry Client using a transmit configuration configured to support that functionality. The only situations under which the Agentry Client should require a second transmit to keep the connection open are:1) The transmit configuration definitions were changed and published to the Agentry Server. This forces the transmit configuration definitions to be downloaded to the Agentry Client, which then requires the user to perform another transmit for the new version of those definitions to take place.2) The Agentry Client entered the Off-Line state for some reason and the user then performs a manual transmit. If the user then mistakenly chooses to remain in an off-line state, they would need to change to an on-line state and then transmit again.Third, the keep alive timing question. You are half right in that the Agentry Server will keep the user logged in if the network connection is lost. It will not actively try to reconnect to the Agentry Client. Rather, the Agentry Client may try to reconnect when attempting to background send a pending transaction. Also, if the user logs off, as you stated in your question, the Agentry Server will not keep the user logged in nor try to maintain a connection with the Agentry Client. When a user logs out of the Agentry Client, the Client notifies the Server and the user is disconnected and logged out.Fourth, the application security attribute Always connect to server from login dialog is the proper setting to track when a user logs in to the Agentry Client. This setting does result in a full standard transmit, which includes data synchronization and updates. There is no method to hide the transmit dialog for this transmit.Fifth, to track a user logging out of the Agentry Client, the module definition includes an attribute Application exit action. This attribute can execute an action that includes a transmit step. When the user exits the Agentry Client this action is executed and would then perform a transmit.
Hope this helps.
Jason Micklevitz
Technical Writer/Training Specialist
Syclo
Ankur Malhotra 05/20/2011 17:42
Hi Jason,I really appreciate your reply. It made things quite clear and will help me design my solution.I have two further questions though. Just trying to understand more.As you said - When a user logs out of the Agentry Client, the Client notifies the Server and the user is disconnected and logged out.What will happen if the user is not in network when he logs off? The server cannot know I think and so the user should not get logged out. Now if the device comes in network, with the Agentry client still logged off (like the user never logged on) - will it notify the server? And next step, while he is in the server, he logs in the device, will the server never know that the client logged off? I think am asking too much, so please pardon my queries.Also you said -
Always connect to server from login dialog is the proper setting to track when a user logs in to the Agentry Client.Can you please be more detailed as to how and where we can keep track when a user logs in to the Agentry Client - Is there any customization required for this tracking?
RegardsAnkur Malhotra
Jason Micklevitz 05/20/2011 18:17
Breaking your last post into two parts, first the network coverage scenario you describe and second regarding how to track the login related to Always connect to server from login dialog:Loss of Network Coverage and Client Log out/Log In:If I understand your scenario, you wish to know what would happen when all of the following are true:Always connect to server from login dialogBackground sending is enabledThe user is moves out of network coverage, severing the network connection from the Client to the ServerThe user subsequently exits the ClientThe user logs back into the Client before the Server expires the connection and logs the user outIn this case, when the user logs back into the Client they will be required to perform a transmit, as I described above. The Server will still have the user logged in, but this will not prevent the behavior I think you are looking for, which I believe is processing the client log in when there was no previously dropped network connection. Put another way, in the scenario as I have listed it, the Client will connect to the Server and perform a full transmit.Tracking Client Login with Always connect to server from login dialog:For a Java back end it would be required that the login() method of the Server class within the Agentry Java API contain the logic and instructions to update the back end system with whatever audit trail should be created to record the Client Login event. NOTE: The applications within Syclo's SMART Mobile Suite For SAP Systems are defined to perform this processing out of the box and, therefore, no additional changes should be necessary, provided you are logging such events according to standard SAP system processes.For a SQL back end, the Agentry Server includes a configuration file SqlBE.ini (see more on this file here: Agentry Server SqlBe.ini Configuration File Sections). Within this file is a section named [LoggedIn]. Under this section can be listed on or more SQL queries to be run whenever a user successfully logs in to the Agentry Server and according to the back end authentication defined for that mobile application. In her a SQL script would be listed to create the audit trail entry in the back end system for such an event.Hope this helps,
Jason MicklevitzTechnical Writer/Training SpecialistSyclo