Quentin P
Rank: #2463
12Views
7Comments
Solved
Native app version number in Service Center doesn't match Lifetime
Question
Lifetime
Service Center

Hi all,

What are the possible reasons that may cause the version number in Lifetime not to match with the number in Service Center and in the generated app? I have tried a few times to re-tag and regenerate and the version number remains as the old number.

0
0
on 2020-11-25
Copy link to comment
Quentin P
Rank: #2463
Solution

Just in case anyone comes upon this issue in the future and finds this thread, I submitted a support case to Outsystems and got this in reply.

After a thorough analysis of this situation and the records provided, we would like to share our progress with you.


Several timeouts have been encountered in your lifetime environment for different processes, we suspect that this may be preventing you from applying the tag to the application.


As a mitigation measure, you can increase the Automatic Activities timeout value (parameter Scheduler.AutomaticActivitiesTimeout) in the environment where they have Lifetime installed, following the steps below:

  1. Run the following query against the environment database:  insert into ossys_parameter (NAME,VAL) VALUES ('Scheduler.AutomaticActivitiesTimeout', '900');

    • Check if the parameter already exists first.

    • This will increase the timeout value to 900 seconds (15 minutes). The default value is 300.

  2. Run an iisreset command at the Command Prompt of any server where the OutSystems Scheduler Service is running, in this environment.

  3. End any running process of the LifetimeEngine module, using BPT Utils or directly through the Service Center.

  4. Trigger a new synchronization.


The issue you are facing seems to be defect RPD-3605, which was fixed in LifeTime Management Console 11.5.1. Please confirm in the Release Notes.

Let us know if the operation is successful after this adjustment.


If increasing Scheduler.AutomaticActivitiesTimeout to 900 is not enough, you can always update the 

created record to a higher value by changing the VAL column to this one.


I was able to update tag and get the version number in Service Center to sync with the one in Lifetime after applying the parameter update. 



See solution in context
1
0
on 2020-11-27
Copy link to comment
Daniël Kuhlmann
mvp_badge
MVP
Rank: #17

Hi Quentin,

The LifeTime App version numbers are a different version number than the native app version number generated by MABS. 

Regards,

Daniel.

0
0
on 2020-11-25
Copy link to comment
Quentin P
Rank: #2463

Hi Daniel,

I was under the impression the version number follows the tagged number in Lifetime as it was 1.34.3 before I tried tagging a new version in Lifetime. If this is not the case, is there a way to update the native app version numbers?

0
0
on 2020-11-25
Copy link to comment
Daniël Kuhlmann
mvp_badge
MVP
Rank: #17

Hi,

Yes that is possible, via LifeTime, Press the Tag Version button on a LifeTime Application

On the screen displayed scroll to the bottom, there you can set the mobile app versions:

0
0
on 2020-11-25
Copy link to comment
Quentin P
Rank: #2463

Hi Daniel,

I'm not sure if this is unclear, as that appears to be what I have already done. You may see that it is showing 1.39 in my first image from Lifetime, and 1.33.2 / 1.34.3 in my second image taken from Service Center.

0
0
on 2020-11-25
Copy link to comment
Quentin P
Rank: #2463

Looking inside the Windows Application logs on the production server,  I also noticed there is a long list of warnings many of which have this error: "Error opening connection to the database: ORA-12570: Network Session: Unexpected packet read error" 

Could this be related to the failure to sync the version numbers?


0
0
on 2020-11-26
Copy link to comment
Daniël Kuhlmann
mvp_badge
MVP
Rank: #17

I don't know but don't hink so.

You still assume that these numbers need to match and that is not true. If I check our mobile apps they also are not matching.


0
0
on 2020-11-26
Copy link to comment
Quentin P
Rank: #2463
Solution

Just in case anyone comes upon this issue in the future and finds this thread, I submitted a support case to Outsystems and got this in reply.

After a thorough analysis of this situation and the records provided, we would like to share our progress with you.


Several timeouts have been encountered in your lifetime environment for different processes, we suspect that this may be preventing you from applying the tag to the application.


As a mitigation measure, you can increase the Automatic Activities timeout value (parameter Scheduler.AutomaticActivitiesTimeout) in the environment where they have Lifetime installed, following the steps below:

  1. Run the following query against the environment database:  insert into ossys_parameter (NAME,VAL) VALUES ('Scheduler.AutomaticActivitiesTimeout', '900');

    • Check if the parameter already exists first.

    • This will increase the timeout value to 900 seconds (15 minutes). The default value is 300.

  2. Run an iisreset command at the Command Prompt of any server where the OutSystems Scheduler Service is running, in this environment.

  3. End any running process of the LifetimeEngine module, using BPT Utils or directly through the Service Center.

  4. Trigger a new synchronization.


The issue you are facing seems to be defect RPD-3605, which was fixed in LifeTime Management Console 11.5.1. Please confirm in the Release Notes.

Let us know if the operation is successful after this adjustment.


If increasing Scheduler.AutomaticActivitiesTimeout to 900 is not enough, you can always update the 

created record to a higher value by changing the VAL column to this one.


I was able to update tag and get the version number in Service Center to sync with the one in Lifetime after applying the parameter update. 



1
0
on 2020-11-27
Copy link to comment