"Implicit" SUT

[cjol]

Some operators of ITP will want to provide a real implementation for test components instead of relying on our simulators. For example, an admin may prefer to use a "real" Mojaloop installation instead of using a fully simulated Mojaloop. We support this by allowing users to create a session with Mojaloop as a SUT.

It's correct to model Mojaloop as a SUT in this situation, because it's external to our system. However, it is inconvenient for users of the platform to add the external Mojaloop as a SUT every time they create a new session.

Instead of this, I propose to add a concept of "Implicit SUT Rules". Each rule consists of a target component slug and a URL. The rules can be added by platform administrators only, and there is no limit to the number of rules (0-N).

During session creation, users are able to select which components are SUTs for the test case. When they enable a component as a SUT, the implicit SUT Rules table should be consulted. If the component slug matches any of the rules, that rule's URL is prefilled as the component URL for the session. Furthermore, the URL should not be editable by the user.

Once #297 has been implemented, the rules should be augmented with another field called "version pattern", which will work in a similar way but using the selected component version instead of the component name.

[cjol]

TODO: the strategy above allows us to send messages from ITP to the component using an automatically determined URL. However, it does not help with receiving messages from the component back to MPOP. The components will need to somehow be configured with the correct URLs to point the current session. This problem is related to #382 but without the benefit of working within a single group. Some design work will be required here.

[cjol]

From @agalaguz in Google Docs:

Our idea was like this - if a particular Component is NOT a SUT on a Session level, messages from it to be a. generated by a platform like it works now b. generated by a real simulator (e.g. Mojaloop build or MMO1/2 or any others)

for option "b" we were thinking to add some switcher on Component (e.g. if BASE URL http://prntscr.com/xd5cy2 exists) or Session levels to where user chooses "let's platform generate everything or let's real Mojaloop installation reply on my messages".

for same option "b" /simulator approach (that includes a traceparent) would work better and won't require to create/update CALLBACKS inside moja every session.

E.g. I create my DFPS's FSIOP-name with CALLBACKS like https://{itp_url}/testing/{my_uuid}/{recipient_uuid}/simulator for a single time. Instead of thinking how to add Moja installation as a "hidden SUT" with a need to update it for every session with such CALLBACKS https://{itp_url}/testing/{session_uuid}/{my_uuid}/{recipient_uuid}/sut

[cjol]

I need to think about this some more. In general, the "implicit SUTs" should not require modification to use with ITP. Luckily Mojaloop will forward the trace headers so it works in this case but if we wanted to use the same principle with an existing MMO simulator we would need to add some logic that reads the traceparent header and passes it onwards.

My expectation was that the implicit SUT would use the /sut URLs like any other SUT. This does come with a slight disadvantage that the callbacks require updating on each session, although this problem is partly mitigated by #382 . I can see that this might not be sufficient for MMO simulators because we don't have an interface for updating callbacks there...

Let me think about it some more!

[agalaguz]

Hi Christopher @cjol, We are to deliver #384 and #297 this sprint, and I guess we are to develop #352 as the next big feature. Could you please have a look if any requirements are to be updated on top of #384 and #297? Thanks!

[cjol]

I Anton, I don't think there are any changed requirements, but I made some diagrams to be more clear about what I'm expecting. For admins, there will be a new page to enter Implicit SUT Rules:

When users are selecting components for their session, it might look like this:

[cjol]

@agalaguz I forgot about encryption when I was putting the above mockups together. In the Implicit SUT rules page, for every URL we should also allow admins to select whether the connection is encrypted, and to provide certificates for an mTLS connection (just like we do when a SUT URL is provided during a session).

[KolyaSirik]

Hi Christopher @cjol , Is version field required on a new page to enter Implicit SUT Rules?

[cjol]

I think we need the version pattern field on the implicit SUT rules (like in my previous screenshot), otherwise we cannot use different URLs for different versions.

Did I misunderstand the question?

[agalaguz]

Thank you for your comments, guys.

Re "is version field required" - we were thinking if it should be mandatory on the Implicit SUT creation page as there can be some simulator that works with ALL API versions. But then we realized that some related patterns can be used for this reason. So, this question is resolved now.

Meantime we noted that there should be some ability to add own SUT URL on the Session creation page E.g. some "checkbox" that allows me to type own 'Mojaloop URL'. Or even checkbox to use Implicit SUT that the platform to add in the disabled field. Am I right? Could you please advise? @cjol

[cjol]

Hi, thanks for clarifying! Yes I think version pattern should be mandatory as you note.

The intended use for the implicit SUT is for platform administrators to simplify session creation for users. For example, we don't expect an MMO to know the correct URL to use for a Mojaloop SUT. So to keep the experience super simple for now, I would prefer that we do not allow the user to enter or change the SUT URL at all if there is a matching rule - even with a checkbox. If we come across a situation in future where users want to "override" the implicit SUT URL, then we can add the feature at that time.