21
Views
6
Comments
Solved
Service Action issue

Hi, guys! 


I understand that service actions create weak references, but at the time of making any modification (I did not change the signature) the module appears as 'outdated' in service center.


This is why i uploaded a new version of the module, but if i don't change the signature (?), is it okay for the module to be 'outdated'?


This confuses developers and they republish consumers wasting a lot of time.


Regards,

Jorge Orellana

Rank: #86
Solution

Hello there Jorge,

Thank you for exposing this scenario.


I did some tests and here's what I can verify:

  • If you only have a Service Action (weak dependency) and publish a new version of the producer module, the consumer indeed appears as outdated in the Dependencies tab.

    However, if you open the consumer module itself, it says that the module is okay.

  • If you change the reference to a Server Action (strong dependency) instead and publish a new version of the producer module, the consumer also appears as "outdated" in the Dependencies tab (same scenario).

    However, if you open the consumer module itself, now it says that the module has outdated dependencies.
    Also a new message appears in the Service Studio (that doesn't appear for the other scenario) saying that the consumer is outdated.


So this seems to be a thing only related with the information that appears on the Dependencies tab that is not quite consistent with the information of the module.

Most likely, it appears as outdated in there just to inform the user that a new version of the producer was published, but the module is not quite outdated (since no messages appear when you open it).


Kind regards,

Rui Barradas

Rank: #86

Hello there Jorge,

Hope you're doing well.

Basically, when you have a producer and a consumer modules, if you publish a different version of the producer, the consumer will become "outdated".

Behind the scenes, the Platform understands that you have a different version and it is just a way to say that the consumer module was not compiled for the newer producer version and it is running an outdated version.

This happens even if you don't change the signature of an action and it is valid for every new deploy on the producer side. Of course, if you publish the same published version of the producer, it won't have any effect.

However, this applies only for strong dependencies. Are you sure that you don't have a strong dependency between those modules that is causing that behavior?


For weak dependencies it is quite the opposite. Changes in the producer side shouldn't make your consumer to be "outdated" and they should take effect immediately.


Kind regards,

Rui Barradas

Champion
Rank: #947

Hello Rui,


I have a module only exposing the service with the text "hello"


I only consume that service action, from a 'serviceEu' module



When changing the text to "bye", there is no type of alert in the service studio, since the signature does not change.



But in service center it already appears as 'outdated'.



Kind regards,

Jorge Orellana 

Rank: #86
Solution

Hello there Jorge,

Thank you for exposing this scenario.


I did some tests and here's what I can verify:

  • If you only have a Service Action (weak dependency) and publish a new version of the producer module, the consumer indeed appears as outdated in the Dependencies tab.

    However, if you open the consumer module itself, it says that the module is okay.

  • If you change the reference to a Server Action (strong dependency) instead and publish a new version of the producer module, the consumer also appears as "outdated" in the Dependencies tab (same scenario).

    However, if you open the consumer module itself, now it says that the module has outdated dependencies.
    Also a new message appears in the Service Studio (that doesn't appear for the other scenario) saying that the consumer is outdated.


So this seems to be a thing only related with the information that appears on the Dependencies tab that is not quite consistent with the information of the module.

Most likely, it appears as outdated in there just to inform the user that a new version of the producer was published, but the module is not quite outdated (since no messages appear when you open it).


Kind regards,

Rui Barradas

Rank: #287

Hi Jorge

Thank you for bringing up this topic, It's interesting.

I thought it's a little weird behavior too. Because this document says service action is loosely coupled elements can be built and published independently 

Kind Regards,

mvp_badge
MVP
Rank: #19

Hi @Jorge Orellana,

I agree it seems a bit confusing for developers, especially for this particular case. However I believe there are still situations where although a consumer may not be impacted directly by the non-breaking changes of a weak reference it is "outdated" in the sense it is not aware of possible changes in the public API - consider for instance the scenario where you add a new optional input parameter, or add an extra output parameter to a Service Action.

All said and done, maybe a better explanation of what outdated means is in order there, but as a workaround "solution" in the meantime, we can teach developers what are non-breaking changes and have them confirm in the consumer if they are actually impacted by them (like @Rui Barradas shows in the SliderValue module's Status)

Cheers!

Champion
Rank: #947

Hi all

Thank you for your answers.

I understand that somehow the consumer module has to be warned of the change, but it does not seem correct to mark a consumer with non-breaking changes as outdated, since if so, the service center information is not aligned with that of service studio , or maybe it would be good to find another way to warn about this change in the module.

Currently we have a somewhat large factory, with many applications and these types of problems (which are not really problems) take us time with the execution of solutions to try to keep the modules updated before a step between environments.

I already have the necessary information to close the topic, thank you very much.


Kind regards, 

Jorge Orellana