Controlling information flow

Experimental Important: This feature is experimental in Finsemble 6.1. It might change substantially over time or it might not be supported in the future. Use at your own risk.

In Finsemble information flows along channels. Any app that is connected to a channel can see anything that appears on it. This works well when you want to broadcast indiscriminately to all the apps on the channel.

In some situations you don’t want to share information or context with all the apps on the channel. Instead, you want to pick specific apps that you trust, and send that information only to them. For example, a bank might want to send some market information only to specific clients, and keep it away from the general client population. In this case, you want to deliberately allow some apps to receive restricted information while excluding others. Similarly, in some situations you don’t want to receive information from all sources. Instead, you want to specify which apps you want to hear from. To achieve this level of control over the flow of information, you must specify which apps you trust.

SelectConnect is a mechanism that provides a powerful declarative interface for this kind of selective integration without coding. Whenever an app broadcasts context, raises an intent, or listens for either, selectConnect redirects the flow of information, so that only approved destinations receive the information. Context and intents can be routed through modules that act upon the interop message flow based on the trust relationships that you can define.

Important Important: If you don’t explicitly specify trust, you trust everyone. If you specify even one trust relationship, this automatically means that you don’t trust anyone else.

You can use selectConnect to authorize an app exchange data with a specific client application. You configure this access in your config file, no coding required. Instead, you specify rules that you want the communication to obey.

Whenever an app broadcasts a context or raises an intent, it places this information on the channel so that other apps can grab it. Similarly, when an app listens for a context or an intent and then finds one, it grabs that data for its own use. The information flows through the channel, and anyone can access it.

SelectConnect restricts this free flow of information. Context and intents can be routed through modules that act upon the interop message flow, while others on the channel don’t even know the information is there.

How to specify trusted flows of communication

Add trust declarations to your config file. You can useSelectConnect to specify the trusted flow of information by using the authorize rule.

Authorize restricts delivery and receipt of messages to authorized endpoints only. An app using the authorize rule can both send and receive data from the apps identified by the rule; it can't send or receive data from any other app. Authorization is by app name.

Authorization restricts communication in both directions.

Example:

Consider 2 apps on the same channel, Blue and Green. You can restrict the order contexts to authorized apps. In our example, app Blue authorizes app Green so that both can exchange privileged information.


      "selectConnect": [
        {
          "contextType": "order",
          "authorize": [{"name":"Green"}]
        }
      ]

Note Note: The Authorize rule defines the trust relationship from the perspective of one app, the one for which you specify this rule. But just because one app wants to communicate, it doesn’t necessarily follow that the other apps must allow this communication. The rule in one app is not binding for the other apps listed in that rule. They can have their own rules, or no rule at all. For example, if we specified an authorize rule for Green that doesn’t list Blue, the communication wouldn’t work.

Properties of trust relationships

The trust relationships have two very important properties. First, trust is not a two-way street. When you specify that app A trusts app B, it doesn’t automatically follow that now app B also trusts app A. If you want the apps to trust each other, you must specify this for each app separately. Also, because all trust relationships must be explicitly declared, trust is not transitive. In other words, if app A can send messages to app B, and app B can send messages to app C, it doesn’t follow that now app A can send messages to app C. If you do want app A to be able to send messages to app C, you must say so explicitly.

When to use

Think of selectConnect as a mechanism to limit authorization. By specifying that you trust an app, you authorize this app to receive restricted information. This is helpful in situations where a company has two different sets of customers. For example, one set includes everyone, and another includes most valued customers only. If you establish trust with the most valued customers, you can send specific information to those customers only. The general public doesn’t get to see this valuable information.

Pitfalls

The trust mechanism is powerful, but you need to be aware of it at all times. If you forget that an app now trusts (or doesn’t trust) another app, you can spend many hours debugging, thinking you have a channel problem. The biggest source of headaches is forgetting to update or check your trust declarations.

Make sure your trust is set up correctly. It’s easy to define that A authorizes B and then forget to check if B authorizes A. Don’t expect this trust relationship to run both ways and verify that you defined it correctly. If you raise an intent for an unauthorized app, that app won’t get the intent. There is no error message. If you have an app that doesn’t receive intents and you expect that it should, verify the trust specification for that app.