Allow changing of SCU Urls after initialization

[volllly]

When the SCU has been connected with the Queue in our Portal and the queue started, it's not possible to change the URL of the connected SCU.

This behavior was intended but often leads to confusion and sometimes broken installations in cases like these:

• The person configuring the Cashbox forgot to change the Port before connecting the queue and needs to change it because of their local configuration already has that port in use
• Someone wants to change the URL before switching the SCU but did so after configuring the switch in the portal

Both result in the SCU URL and the URL in the init_ftSignaturCreationUnitDE not being equal and the middleware not starting correctly.

Should we rethink this behavior for it to be possible to update the SCU URL after the SCU and Queue have been connected / the switch has been configured?
@saschaknapp @StefanKert

[saschaknapp]

Bringing this discussion back...
It would be really helpful if the SCU URL could be changed after initialization. I now have a case where the customer forgot that the FCC can only be installed once. He needs to create new queues and therefore needs to connect these to the existing FCC. But this isn't possible because the SCU URL is configured for "localhost" and that results in the new queues not being able to connect to the SCU. The customer needs to change the localhost URL in the SCU config to the IP address of the system but this is not possible because we don't allow to change the URL in the init_ftSignaturCreationUnitDE :/ Can we please discuss this? @volllly @StefanKert @TSchmiedlechner

[volllly]

He needs to create new queues and therefore needs to connect these to the existing FCC

If I got that correctly that should not be a problem... the thing is the SCU url can be changed but an already initialized Queue will not use the changed url but still the old one.

If the Queue is new and not yet initialized it will take the new SCU url.

But generally I'm also in favor of allowing the changing of SCU urls after initialization. (if only because its super intransparent and hard to reason about like its now)

[saschaknapp]

It's true this isn't a problem for the new queues, but the already initialized old queue will stop working as soon as we change the SCU URL :(

[volllly]

Ah I did not understand the old queue will still be used. Would it work to have both the old and new urls configured in the SCU?

[saschaknapp]

Great question. I don't know. Does the queue always use the first configured URL for the init_? If so, then this wouldn't work.

[volllly]

The old queue will still use the original url that was configured when it was initialized and the new queue will use the first configured grpc url (and if no grpc url is configured just the first url).

So I think you could put the new url as the first url and then It should work.

EDIT: This would not work. See Stefans reply below as to why.

[StefanKert]

Hi folks,

It seems as if we are also not able to change the SCU URL s before the Queue has started. Actually after connecting Queue + SCU changes in the SCU Port are not reflected anymore. This behavior is currently the same for all markets. While we are able to change the URL of the SCU that is being hosted in the Launcher via the SCU Dialog, the Queue uses the init_SignaturCreationUnitDE field for that which is filled by the Connection properties. These connection properties are not propagated if we update the SCU Url which is the main cause of this issue.

@wrueting I guess you are solving this in AT by "removing" and "adding" the SCU again in the connection dialog, which is not really perfect but at least a workaround.

For DE since it is not really easy to remove a SCU we cannot use this workaround.

Right now I think that there is no case where one can change the URL in the SCU, Rebuild and keep on working. Since during the Rebuild the SCU URL would be updated, but the one that is configured in the Queue not we would run into troubles.

I am actually wondering why we don't have these issues more frequently.

So long story short, IMO we have to allow changing the URL that is being used for connecting the Queue + SCU. I was trying to think a bit about the risks here, but IMO the risk of not changing it is also pretty high:

e.g.
SCU 1 => grpc://localhost:2012

we want to perform a SCU switch and therefore update the configs in the following way
Change url of SCU 1 => grpc://localhost:2013
Add SCU2 with url => grpc://localhost:2012

So after the rebuild and the next start the Queue would use SCU2 even though it is looking up the URL via the correct Id and so on.

One thing we should also consider is scenarios where SCUs are hosted in a different CashBox than the one that we are using. This is one of the reasons why this was implemented like this in the first place.

Scenario:

1. SCU 1 is hosted on Server A and uses rest://localhost:1239. For security reasons the SCU is made available via reverse proxy through the public endpoint https://scu.servera.signingde.svc
2. Queue is configured to use SCU 1 via the url https://scu.servera.signingde.svc

This scenario seems a bit unrealistic in Germany but it is something that we definitely have in Austria and will probably have in other markets.

[volllly]

fiskaltrust/engineering#42