Standard message config for In Out topics - Revision history

Sven the Barbarian at 13:59, 10 May 2021

2021-05-10T13:59:54Z

← Older revision		Revision as of 13:59, 10 May 2021
Line 30:		Line 30:
	..		..
	],		],
			activitySwitchboard: true\|false, //default: false, if set to false Activity Switchboard service will not setup a subscription to receive these messages
	allowAdditionalProperties: true\|false, //default: true, if false only the specified properties are allowed		allowAdditionalProperties: true\|false, //default: true, if false only the specified properties are allowed
	}		}

Sven the Barbarian: /* MsgCfg syntax */

2021-05-10T13:49:39Z

MsgCfg syntax

← Older revision		Revision as of 13:49, 10 May 2021
Line 11:		Line 11:
	<syntaxhighlight lang="JavaScript">		<syntaxhighlight lang="JavaScript">
	{		{
	serviceName:		serviceName: xx
	topicName:		topicName: yy
	properties:{		properties:{
	{propertyName}:{		{propertyName}:{

Sven the Barbarian: /* MsgCfg syntax */

2021-05-10T13:49:28Z

MsgCfg syntax

← Older revision		Revision as of 13:49, 10 May 2021
Line 11:		Line 11:
	<syntaxhighlight lang="JavaScript">		<syntaxhighlight lang="JavaScript">
	{		{
	topicName: ~~//string name of topic, is the full SNS topic name including service/stage~~		serviceName:
			topicName:
	properties:{		properties:{
	{propertyName}:{		{propertyName}:{

Sven the Barbarian: /* MsgCfg syntax */

2021-05-06T15:01:46Z

MsgCfg syntax

← Older revision		Revision as of 15:01, 6 May 2021
Line 11:		Line 11:
	<syntaxhighlight lang="JavaScript">		<syntaxhighlight lang="JavaScript">
	{		{
			topicName: //string name of topic, is the full SNS topic name including service/stage
	properties:{		properties:{
	{propertyName}:{		{propertyName}:{

Sven the Barbarian: /* Validation of outgoing messages */

2021-05-03T13:57:35Z

Validation of outgoing messages

← Older revision		Revision as of 13:57, 3 May 2021
Line 38:		Line 38:
	= Validation of outgoing messages =		= Validation of outgoing messages =

	* Can add to middleware function/s for validating sent messages adheres to ~~this services~~ MsgCfg setting		* Can add to middleware function/s for validating sent messages adheres to MsgCfg setting
	* ~~All~~ messages sent to ~~MsgOut must~~ have a matching MsgCfg value		* messages sent to topics can have a matching MsgCfg value, if have can use this to validate the message before sending
	* Might need a separate middleware function that processes and validates messages sent to In / Out topics, before processing standard SNS middleware request		* Might need a separate middleware function that processes and validates messages sent to In / Out topics, before processing standard SNS middleware request
	* Maybe split In and Out into different middleware functions, Out can hardcode topic sent to		* Maybe split In and Out into different middleware functions, Out can hardcode topic sent to

Sven the Barbarian: /* MsgCfg syntax */

2021-05-03T12:28:43Z

MsgCfg syntax

← Older revision		Revision as of 12:28, 3 May 2021
Line 6:		Line 6:

	= MsgCfg syntax =		= MsgCfg syntax =

			* unique key of each msgCfg is the {serviceName}_{topicName}

	<syntaxhighlight lang="JavaScript">		<syntaxhighlight lang="JavaScript">
	{		{
	~~topic: {string}~~
	properties:{		properties:{
	{propertyName}:{		{propertyName}:{

Sven the Barbarian: Sven the Barbarian moved page Standard MsgIn MsgOut message config to Standard message config for In Out topics

2021-04-17T15:24:24Z

Sven the Barbarian moved page Standard MsgIn MsgOut message config to Standard message config for In Out topics

← Older revision	Revision as of 15:24, 17 April 2021
(No difference)

Sven the Barbarian at 15:23, 17 April 2021

2021-04-17T15:23:17Z

← Older revision		Revision as of 15:23, 17 April 2021
Line 1:		Line 1:
	~~= No longer used =~~

	Due to AWS SNS limits, specifically account level filter policy limits, the combined MsgIn/Out queue idea will not be feasible, the alternative will be a specific queue for each message type (ie: msgTag), the msgTag will no longer be needed, instead the SNS queue can be checked to see type of message by services/functions that receive multiple message types.

	~~AWS accounts allow 200 filter policies per account, used to be 100, appears to be a relatively hard limit, not a lot of chatter about requesting increases.~~

	= Overview =		= Overview =

	All messages sent to ~~MsgIn~~ or ~~MsgOut~~ SNS ~~queues~~ have a ~~hardcoded~~ configuration, this is used by the [[Service - Message Config Manager\|Message Config Manager]] service ~~which~~ stores every MsgCfg for every service in the project, which can then be used for example by ~~client~~ that sets up user notifications, or [[Service - Activity Switchboard\|Activity Switchboard]] service.		All messages sent to In or Out SNS topics have a configuration schema, this is used by the [[Service - Message Config Manager\|Message Config Manager]] service that stores every MsgCfg for every service in the project, which can then be used for example by the frontend that sets up user notifications, or [[Service - Activity Switchboard\|Activity Switchboard]] service.

	~~This configuration can~~ also be used to validate messages being sent are formatted correctly.		The MsgCfg could also be used to validate messages being sent/received are formatted correctly.

	= MsgCfg syntax =		= MsgCfg syntax =
Line 15:		Line 9:
	<syntaxhighlight lang="JavaScript">		<syntaxhighlight lang="JavaScript">
	{		{
	~~msgTag~~: {string}		topic: {string}
	properties:{		properties:{
	{propertyName}:{		{propertyName}:{
Line 33:		Line 27:
	..		..
	],		],
	~~activitySwitchboard: true\|false, //default: false, if set to false Activity Switchboard service will not setup a subscription to receive these messages~~
	allowAdditionalProperties: true\|false, //default: true, if false only the specified properties are allowed		allowAdditionalProperties: true\|false, //default: true, if false only the specified properties are allowed
	}		}
Line 46:		Line 39:
	* Can add to middleware function/s for validating sent messages adheres to this services MsgCfg setting		* Can add to middleware function/s for validating sent messages adheres to this services MsgCfg setting
	* All messages sent to MsgOut must have a matching MsgCfg value		* All messages sent to MsgOut must have a matching MsgCfg value
	* Might need a separate middleware function that processes and validates messages sent to ~~MsgIn~~ / ~~MsgOut~~, before processing standard SNS middleware request		* Might need a separate middleware function that processes and validates messages sent to In / Out topics, before processing standard SNS middleware request
	* Maybe split ~~MsgIn~~ and ~~MsgOut~~ into different middleware functions, ~~MsgOut~~ can hardcode topic sent to		* Maybe split In and Out into different middleware functions, Out can hardcode topic sent to

	= Validation of incoming messages =		= Validation of incoming messages =
Line 55:		Line 48:
	= Notes =		= Notes =

	* If developers change ~~the msgTag~~, ~~dependant~~ services will likely break (eg pointers in notification service will no longer match), must be careful doing this		* If developers change an In / Out topic's name, dependent services will likely break (eg pointers in notification service will no longer match), must be careful doing this
	* If update other config settings, eg expected/optional parameters, will need to get ~~dependant~~ services to re-build, eg [[Service - Activity Switchboard\|Activity Switchboard]] service will need to rebuild its local database MsgCfg's		* If update other config settings, eg expected/optional parameters, will need to get dependent services to re-build, eg [[Service - Activity Switchboard\|Activity Switchboard]] service will need to rebuild its local database MsgCfg's
	* [[Service - Notification Manager\|Notification Manager]] service does not need to link to a real ~~MsgTag~~, eg if ~~MsgTag~~ gets changed or removed we don’t have to remove them from users notifications configs, those configs will simply stop ~~filtering accurately~~ (although best to clean up, but we could periodically do that rather than trying to clean up each time there is a change)		* [[Service - Notification Manager\|Notification Manager]] service does not need to link to a real topic, eg if topic gets changed or removed we don’t have to remove them from users notifications configs, those configs will simply stop receiving messages (although best to clean up, but we could periodically do that rather than trying to clean up each time there is a change)

Sven the Barbarian: /* No longer user */

2021-04-05T14:22:11Z

No longer user

← Older revision		Revision as of 14:22, 5 April 2021
Line 1:		Line 1:
	= No longer ~~user~~ =		= No longer used =

	Due to AWS SNS limits, specifically account level filter policy limits, the combined MsgIn/Out queue idea will not be feasible, the alternative will be a specific queue for each message type (ie: msgTag), the msgTag will no longer be needed, instead the SNS queue can be checked to see type of message by services/functions that receive multiple message types.		Due to AWS SNS limits, specifically account level filter policy limits, the combined MsgIn/Out queue idea will not be feasible, the alternative will be a specific queue for each message type (ie: msgTag), the msgTag will no longer be needed, instead the SNS queue can be checked to see type of message by services/functions that receive multiple message types.

Sven the Barbarian at 14:21, 5 April 2021

2021-04-05T14:21:57Z

← Older revision		Revision as of 14:21, 5 April 2021
Line 1:		Line 1:
			= No longer user =

			Due to AWS SNS limits, specifically account level filter policy limits, the combined MsgIn/Out queue idea will not be feasible, the alternative will be a specific queue for each message type (ie: msgTag), the msgTag will no longer be needed, instead the SNS queue can be checked to see type of message by services/functions that receive multiple message types.

			AWS accounts allow 200 filter policies per account, used to be 100, appears to be a relatively hard limit, not a lot of chatter about requesting increases.

	= Overview =		= Overview =