The Request Manager is used to define the details of an incoming request. The contents of this block will vary depending on the type of API it is connected to (see the Transaction manager for API configuration details).
Within the control panel, you can specify the structure of the request:
The Transaction defined in the request manager can be triggered in several ways. The most common is for it to be triggered from an API call inbound to the GLU.Engine. However, it is also to trigger the transaction through setting up a schedule to trigger itself OR on startup of the GLU.Engine, at which the transaction can be set up to only run once on startup.
Scheduled Tick Box
The Schedule and the “run on startup” are mutually exclusive.
Currently, Scheduler, Quartz, Cron & Timer are features that are available to use.
Scheduler
The scheduler feature can be set up for all the REST methods, i.e. PATCH, POST, etc.
The Scheduler feature allows repeatable transactions to be triggered by a scheduler. Each time the API is triggered, it is like a new API request triggering the transaction. This means Derived Parameters and Handlers in the API Request are all actioned. It is also possible to set default values in the inbound parameters and these will take effect.
The Scheduler feature enables the automation of repeatable transactions via scheduling. Each time the scheduler runs the API call triggered is treated as a new request and all associated Derived Parameters and Handlers are executed. Request parameters associated with the API will be passed as null unless default values are set at which point these will be taken for the transaction.
Delay: This is the value for the delay between each transaction being repeated. This value cannot be 0.
example: 10
(If left empty then the default value will apply of 500)
Initial Delay: This is the delay before the first transaction is issued. This value can be 0.
example: 5
(If left empty then the default value will apply of 1000)
Repeat Count: This is the number of times which the transactions will be iterated. If this value is set to 0 then it will repeat for ever.
example: 6
(If left empty then the default value will apply of 0)
Time Unit: for INITIAL DEALY and DELAY.
POSSIBLE Values:
NANOSECONDS, MICROSECONDS, MILLISECONDS, SECONDS, MINUTES, HOURS, DAYS
example: SECONDS
Is used to trigger an API to start repetitively at a fixed time based on the configuration. It works in the same way as a cron job is scheduled in linux.
Quartz
Quartz allows you to schedule repeated running of an API based on a frequency from the point the GLU.Engine starts up. The counter settings all happen from the point the GLU.Engine has started.
Repeat Count: With this feature, you can define how many times a job should be repeated. By setting the repeat count to a specific number, such as 3, Quartz will automatically execute the job the specified number of times.
Repeat Interval: This feature determines the time gap between consecutive job executions. By setting a repeat interval, such as 10 seconds (10,000 milliseconds), Quartz will schedule the job to run at regular intervals, ensuring efficient and timely execution.
Trigger Start Delay: This feature allows you to introduce an initial delay before a job starts executing. By specifying a delay in milliseconds, such as 5 seconds (50,000 milliseconds), you can ensure that the job begins its execution after a specific interval from the scheduler’s start.
Time Zone: To ensure consistent scheduling across different time zones, Quartz provides a parameter to specify the time zone in which the scheduler operates. You can set the desired time zone, such as “GMT” or “America/New_York,” ensuring that the scheduled jobs align with the intended time zone, regardless of the system’s default setting.
Cron
The schedule expression can be made of 5 to 7 parts that represent the timing of the job. When expressions are composed of 6 parts, the first items is the “seconds” part (and year is considered missing). Each field represents a specific unit of time and can have a range of values.
The first field represents seconds (0-59 or *) this is optional.
The second field represents minutes (0-59 or *).
The third field represents hours (0-23 or *).
The fourth field represents the day of the month (1-31 or *).
The fifth field represents the month (1-12 or *).
The six field represents the day of the week (0-7; both 0 and 7 represent Sunday or * or MON-FRI).
The seventh field represents year this is optional.
Examples
- 0 1 * * *
means the API will run at 1:00 AM every day.
0/3 10 * * * ?
Triggers an API every three seconds only in the tenth minute of each hour.
0/2 * * * ?
5 parts, an API call every two minutes
0 0/2 * * * MON-FRI 2030
7 parts, an event every two minutes for Week Days only in year 2030
Timer
An Inbound Connector needs to be configured, typically as a simple REST Inbound Connector. It’s against this Connector that the scheduler configuration is defined. Additionally, it is also possible that even though the transaction is scheduled to run as ‘self-initiated’, this Inbound Connecter API can also be called from an external system.
The API Context Name is not applicable in this case however the Method, Content Type, Save Request As, and Add to INFO Logs are all applicable.
PERIOD:
Similar to DELAY in Scheduler, i.e.
This is the value for the delay between each transaction being repeated (however in microseconds).
This value cannot be 0.
example: 1000 (for 1000 microseconds, 1 second)
(If left empty then the default value will apply of 500)
DELAY:
Similar to INITIAL DELAY in Scheduler, i.e.
This is the delay before the first transaction is issued (however in microseconds).
This value can be 0.
example: 2000 (for 2000 microseconds, 2 seconds)
(If left empty then the default value will apply of 1000)
REPEAT COUNT
This is the number of times which the transactions will be iterated. If this value is set to 0 then it will repeat for ever.
example: 6
(If left empty then the default value will apply of 0)
Run once on startup Tick Box
If this is ticked then the Transaction will trigger itself only on the startup of the GLU.Engine. This will work with all inbound protocols.
Context Name
Within the Request Manager Control Panel, assign a ‘Context Name’. This is the API path, the part after the common path that is defined in the API tool.
For example, if https://devportal.com/api/clients/8a85877a5e4ef2b767/loans is the full URL for a particular call.
The https://devportal.com/api part is the ‘Common Path’ that is defined in the Connectors.
The /clients/8a85877a5e4ef2b767/loans is the ‘Context Name’ that is defined here.
The combination of the ‘Common Path’ and the ‘Context Name’ together makes up the full path or URL for a particular call.
The ‘Context Name’ is used to differentiate different Transaction Types of transactions.
For consistency, it’s recommended to add the ‘forward slash’ ‘/’ to the front of your Context Name … but this isn’t mandatory as GLU will add it if you don’t when building the URLs.
Context Name with Parameters
GLU allows for the use of a parameter within the definition of the context name. The parameter can be defined inside the context name when using the syntax: {parameterA} See below for example:
To successfully unmarshal this parameter, the following three items must be included in the configuration:
- A request parameter must be created
- The unmarshalling parameter attribute Name must be aligned to the context name
- The source ‘From’ must be selected as the header.
Context Name & Route Versioning
Route Versioning (where you include a version indicator such as /v1/ or /v2/ into the URI via the Context Name field) is generally considered to be a clear and concise mechanism for the API user to ensure they are consuming the correct API version and to reference the correct documentation. In this way, you can expose multiple versions of an API on the same GLU.Engine until such time as ‘legacy’ versions are ready to be deprecated at which time you can simply remove that version from the config. In such cases, it is advisable to include a Handler to return a 30x HTTP Response Code with an appropriate Error Message to advise any system that attempts to connect to a deprecated API version that that version is no longer in use.
As an alternative to Route Versioning is to include the versioning in the Header information.
This article provides some further insight into the topic of API Version Controls.
article on versioning
Method
Based on the Initiating System Protocol the ‘Method’ drop-down options will be presented.
The available request types vary depending on the overarching API specification.
Selecting either GET or DELETE (available for HTTP/REST calls) will remove the ability to define a Content Type (see below).
Save Request As
The “Save Request As” field is used to record the datetimestamp of when the transaction was initiated in a variable which could then be used later in the Application.
This is used if for instance an audit of when the APIs need to be recorded in a Database. The parameter as part of orchestration could record the value in a database.
Add To INFO Logs
This check box should be ticked if the value from the Save Request As (i.e. the datetimestamp API is triggered) should be put in the logs.
This is put in the Logs if the logging is set to INFO.
Throttle Panel
Controls the number of transactions to put through for a period of time, i.e. 5000 transactions in 400ms
see Managing Load with Throttles for details.
Time Period (milliseconds)
The Time period the number of transactions will be controlled to. i.e. 400ms
Requests Per Time Period
The number of transactions to control i.e. 5000
