Determining what elements are incompatible for consumer module

Hey guys,

I'm building a small application to present a list of incompatible modules to the user (developer).

I get that I can use the Espace_Runtime entity to get the compatibility status of each espace.
And that I can use Espace_Reference to see each reference for that module, though.... I'm unclear how to determine what element is incompatible or not, do I have to do something with the Hashes to determine compatibility? The Is_Broken and Missing_Status are both still set to 0 even though the module itself has an incompatibility warning....

Hi Joey Moree

Having the eSpace runtime broken attribute (boolean), you need to match what were the changes between two (or more) versions of eSpaces (in terms of entities, apis, etc). Those will form your algorithm to get the mismatch between versions of eSpaces. And I would assume that any implemented logic might be different from the one OutSystems use.

But your project is interesting, are you going to share it later on the forge?

Regards!

Marco Arede wrote:

Hi Joey Moree

Having the eSpace runtime broken attribute (boolean), you need the algorithm to match the missing information between versions of eSpaces. 

Interesting project you are doing, can you share later on the forge?

Regards!


If I get it working that's the plan yeah, currently it's a pain trying to find all incompatibles. (currently I'm using some javascript to fetch it from the solution page).

But I thought it'd be faster to create a page to list all incompatibles/outdated instead, but I'd love to provide some extra information, what's outdated, what's broken etc.

Currently I have no idea what I can use to figure out what is outdated/incompatible and what is valid.

I've updated my previous answer (see above), maybe it helps to get closer to a solution.

I found out I can compare the compatibility hash with the OSSYS_MODULE_PUBLICELEMENT table.

However I am unable to consume this normally within outsystems :( 

Edit, nope OSSYS_MODULE_PUBLICELEMENT seems to be the same as Espace_Reference....

Joey Moree

Would a check by eSpaces version change help? 

I'd assume that an entity changes generates a new instance.

Cheers!

Marco Arede wrote:

Joey Moree

Would a check by eSpaces version change help? 

I'd assume that an entity changes generates a new instance.

Cheers!


It would help, but that way I would only be able to guess, what espace is causing a incompatibility.

I'd love to find a way to get the exact action/structure/extension/entity that is causing it.

So I can get the information on the module that is using these elements, but I have no way to find out the latest version of these elements.

Again I could check their usage in a module which isn't incompatible and compare the hashes on that one, but what if the developer has published none of the incompatible modules? Then I would have no way to figure this out.

Do you know of a way to determine the current version of an element? (albeit an action, entity, structure etc).

From the data model we can see each element to associated to an eSpace record (with a version), where there is a flag to mark invalid eSpaces:

Each version of eSpace contains elements, when an element is modified a new record is associated to that eSpace version (the old one still exists but not associated to new version):

And also there is an entity that you might want to check for modified elements:

I hope this helps you!

Hey Marco,

How would I match the ModifiedElement back to my ESpace? PublishingId is not the same as PublishId (this is some sort of hash).

The easiest (I think) way to solve this, is to be able to match the Compatibility_Signature_Hash (Espace_Reference) from the consumer with the version in the producer.

I am able to determine that something is wrong, but unable to find out what Espace and what elements are causing this.

Update, I found out!

I am able to use the lifetimeAPI to get the current data.

I'm also an idiot it seems, I am able to get the latest versions of each module in lifetime api, however I am unable to match them to a module. (though I do know the application, so I could limit the search slightly).

Is there a way to get the VersionKey easily from the database? Or lifetime perhaps?

Currently I can get all versions (which can be over 9000!!!) and then filter locally to see if it matches one of the current versions in the application.

A module (eSpace or extension) has publishing details in their corresponding entities:

Then follow-up on the connections maybe you find also interesting the publishing entity (to get the last version key, I believe has attribute):

Nono, not the version_id, the version key for lifetime. It is simular to the SS_Key structure (the hash format).

I found that the SS_Key can be used to fetch module from lifetime easily, but there's no easy way to fetch the latest version.

Nvm I got it, I'm checking what modules are incompatible, get all their producers from the database.

Fetch the module details from lifetime for that producer to see their current version in the current environment.

Then get all public elements for that version from lifetime to compare it to the ones in my consumer module.

Return a list of elements that are not compatible.

That seems an executable way to do it Joey, good luck!

Marco Arede wrote:

That seems an executable way to do it Joey, good luck!


It's so slow though! I understand why service center has so much issues with performance :P 

I might create a timer to fetch data every once in a while, to store it in an entity for quicker access.

But atleast I got it working, an overview of every element inside a espace which is outdated/incompatible.

Good one! :) 

I'd try first query optimization inside joins.

Marco Arede wrote:

Good one! :) 

I'd try first query optimization inside joins.


The SQL barely takes any time (in my personal experience SQL is rarely the cause of my problems).
Like only a few MS to get the complete data on all applications/modules within the environment.

It's just fetching the data from lifetime is taking some time.


Though for some reason I am unable to find RichWidgets or Charts in lifetime.....

LifeTime does many processes behind ;)

I found something interesting for you (regarding the application keys to query LT):

https://success.outsystems.com/Documentation/11/Reference/OutSystems_APIs/LifeTime_Deployment_API_v2/LifeTime_Deployment_API_Examples

Maybe is a step to check if modules have the same key as applications.

Solution

Marco Arede wrote:

LifeTime does many processes behind ;)

I found something interesting for you (regarding the application keys to query LT):

https://success.outsystems.com/Documentation/11/Reference/OutSystems_APIs/LifeTime_Deployment_API_v2/LifeTime_Deployment_API_Examples

Maybe is a step to check if modules have the same key as applications.

Hey Marco, 

It's finished, sorta a first version for P10.
I'm indeed using lifetime to get the latest version (which I store in an entity for quicker access, because lifetime is slow.... it's a performance upgrade from 90 seconds to about a little under 10 seconds for 100+ modules)

https://www.outsystems.com/forge/component-overview/5875/incompatibleapplications

I don't have a lifetime server for P11 :( 

For our enterprise environment it works pretty good, clicking the link will also open the module in service studio, talk about convenient.

Let me know what you think!

Solution

Hi Joey Moree,

Inside you can give a context (helper) for how it works, including in settings how to configure.

On the rest my only additional observation is upgrate it to P11 :)

Cheers!

Marco Arede wrote:

Hi Joey Moree,

Inside you can give a context (helper) for how it works, including in settings how to configure.

On the rest my only additional observation is upgrate it to P11 :)

Cheers!


Yup working on P11 upgrade now, will be finished in a bit.

https://www.outsystems.com/forge/component-overview/5875/incompatibleapplications

Updated to P11!

Might work on some other improvements once I have time.

Very well, I think that will help the community and save us time (rather than each one upgrading the application on their side). Cheers!