User Tools

Site Tools


Sidebar

Nebol Software Projects:

.NET Class Libraries

Contact info:

johan@nebol.se

nebolintegration_flags

Possible values for the flags in the Integration table:

	/// <summary>
	/// The Status field of the Integration table. NOT the same as the Status field in the IntegrationQueue table.
	/// </summary>
	public enum IntegrationStatusEnum
	{
		/// <summary>
		/// If the Status is Invalid (0) then it's an indication that something is very wrong, that should never happen
		/// </summary>
		Invalid = 0,
		/// <summary>
		/// If Status is Enabled then the integration is... enabled. 
		/// </summary>
		Enabled = 1,
		/// <summary>
		/// If Status is Paused, submits are accepted, queue is filling up, but NOT processed until integration is Enabled again
		/// </summary>
		Paused = 2,
		/// <summary>
		/// If Status is Ignored, queue is NOT filling up, submits are totally ignored. 
		/// </summary>
		Ignore = 3,
		/// <summary>
		/// NOT FULLY IMPLEMENTED YET, DO NOT USE!
		/// If Status is Scheduled then there is a schedule for when the integration should be enabled
		/// Useful for dealing with service windows so there is no need to Pause/Enable the integration manually in the middle of the night
		/// The status will be inferred from a schedule in the IntegrationSchedule table. 
		/// Default is Enabled. Higher status overrides lower, ie if schedule A says the integration
		/// is Enabled and schedule B says it's Ignore, then status is Ignore
		/// </summary>
		Scheduled = 4
	};
 
	/// <summary>
	/// This is the values for the Direction field 
	/// Mostly for information, but it is also used for dealing with healthchecks:
	/// If Direction is Outgoing and a healthcheck says there is a problem then it will not try to send anything
	/// If Direction is Incoming and a healtchcheck says there is a problem, Connection will still be Up and it will STILL accept incoming calls
	/// </summary>
	public enum DirectionEnum
	{
		/// <summary>
		/// It should never be None (0), if it is then there's a problem
		/// </summary>
		None = 0,
		/// <summary>
		/// This is an Outgoing integration meaning it will make calls to another service
		/// </summary>
		Outgoing,
		/// <summary>
		/// This is an Incoming integration meaning it will accept calls from another service
		/// </summary>
		Incoming,
		/// <summary>
		/// Not outgoing nor incoming, perhaps just a local task
		/// </summary>
		None
	}
 
	/// <summary>
	/// The Connection field is used for dealing with healthchecks
	/// An integration can be Enabled but if a healthcheck says that Connection is Down it will not make any outgoing calls
	/// </summary>
	public enum ConnectionEnum
	{
		/// <summary>
		/// Connection is Down. No calls will be made until it's Up again
		/// </summary>
		Down = 0,
		/// <summary>
		/// Connection is Up. All good.
		/// </summary>
		Up
	};

Possible values for the flags in the IntegrationQueue table:

	/// <summary>
	/// The Status field for the IntegrationQueue, not the same as the Status field for the Integration
	/// </summary>
	public enum StatusEnum
	{
		/// <summary>
		/// This is a new item that has not been processed yet
		/// </summary>
		New = 1,
		/// <summary>
		/// This was successfully processed, nothing more will be done
		/// </summary>
		Success = 2,
		/// <summary>
		/// There was an error, it will try again according to the RetryScheme of the integration
		/// </summary>
		Error = 3,
		/// <summary>
		/// It has been rejected completely, it will not try again (because it would just fail again)
		/// This will never be accepted, there could be a permanent error in the data etc
		/// </summary>
		Rejected = 4,
		/// <summary>
		/// This status means that it has tried so many times, it is time to give up.
		/// </summary>
		GaveUp = 5
	}
 
	/// <summary>
	/// The Command field is used to directly control the integration, to override what should be done with the IntegrationQueue item
	/// </summary>
	public enum CommendEnum
	{
		/// <summary>
		/// No special action
		/// </summary>
		None = 0,
		/// <summary>
		/// The request will be tried again, immediately (not wait according to the schedule)
		/// It doesn't matter what the current status is, even if it is Success it will still try again.
		/// </summary>
		Reprocess_Request = 1,
		/// <summary>
		/// This command will make it give up immediately, do not try again (even if the schedule says so)
		/// </summary>
		GiveUp = 2,
		/// <summary>
		/// This command will process the RESPONSE again. (It will call the ProcessResponse() method if you have overridden that method)
		/// For example, if you have split it up so that in ProcessRequest() you call an API to get some data, and then in ProcessResponse()
		/// you process that data and store it tables.... and you don't want to call the API again to get new data, you just want to 
		/// try to process it again, using the same data as the first time.
		/// </summary>
		Reprocess_Response = 3
	}
nebolintegration_flags.txt · Last modified: 2021/09/27 01:29 by nebol