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 }