...

1. There might be multiple instances of a rhythm service, but only one event should be sent. (Currently, this use case is prepared for, but not completely implemented.)
2. Unlike most other services, the tenant is not part of the request which causes an action to be started.  Only the time of day is.  For this reason, the beat specifications cannot be saved in a tenant-specific table.  Since we don't want to set up one rhythm service per tenant, internally there must be one table for all tenants.
3. Calls to the other services should be made in a secure fashion.  The "beat" is clock-initiated not user-initiated.  A user token cannot be used to authorize the action.

Troubleshooting Deployment of Rhythm And Portfolio

If you aren't getting daily interest calculations in portfolio, please check the following aspects of  your deployment:

1. There should be only one instance of rhythm running.
2. In the configuration for rhythm, rhythm.user should be set to a valid user in your system.  I'll pretend you named it imhotep from here on.
3. In portfolio, portfolio.bookLateFeesAndInterestAsUser should be set to a valid user in your system.  I'll pretend you also named it imhotep from here on.
4. Rhythm's user should have permission to the identity endpoint for creating permission requests for other services, and for the application which is to receive the beats. Its role should contain change permissions for identity__v1__app_self, and, for example, portfolio__v1__khepri
5. Rhythm the application should have permission to act in the name of its user to access the identity endpoint for creating permission requests for other services. /applications/rhythm/permissions/identity__v1__app_self/users/imhotep/enabled should return true.
6. Rhythm the application should have permission to act in the name of its user to call portfolio's beat endpoint. /applications/rhythm/permissions/portfolio__v1__khepri/users/imhotep/enabled should return true.