Allow changing of SCU Urls after initialization #154
-
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:
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? |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 6 replies
-
Bringing this discussion back... |
Beta Was this translation helpful? Give feedback.
-
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. we want to perform a SCU switch and therefore update the configs in the following way 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:
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. |
Beta Was this translation helpful? Give feedback.
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 …