Handling Special Characters

The GLU.Engines will not manipulate the following special characters throughout the integration flow.


Backspace to be replaced with “\b”

Form feed to be replaced with “\f”

Newline to be replaced with “\n”

Carriage return to be replaced with “\r”

Tab to be replaced with “\t”

Double quote to be replaced with \”

Backslash to be replaced with “\\”


As presented in the inbound integration payload, or an inbound connector, they will be passed on without being adjusted.

Derived Parameters Functions & Formulas

Derived Parameters support the use of FUNCTIONS and FORMULAS. A single Derived Parameter can only be used with one FUNCTION i.e. you can’t mix two FUNCTIONS into one Derived Parameter. If for example, you need a Derived Parameter to calculate the difference in the time NOW ( which is a FUNCTION) and another parameter, you can use the DIFFTIMESTAMP but you’ll first need to define a Derived Parameter call say ‘timeNow’ using the NOW FUNCTION and thereafter use the DIFFTIMESTAMP FUNCTION with FUNCTION notation as follows: DIFFTIMESTAMP(${timeExpiry}-${timeNow})

For some functions where it does not update return values such as removing data from cache, the Run Functions tick box should be used.

All functions are accessible through the Predefined Functions feature.

FORMULAs involve the use of mathematical calculations and are always prefixed with the ‘=’ symbol. FUNCTIONs are not preceded by any symbol.

Contents
1 GLU Formulas
1.1 Addition Formula
1.2 Multiplication Formula
1.3 Division Formula
2 GLU Functions
2.1 INITIALISE
2.2 IFNULL Function
2.3 IFEMPTY Function
2.4 IFNULLOREMPTY Function
2.5 SPLIT Function
2.6 CREATE_VALUE_AS_STRING_FROM_ARRAYS
2.7 ADD_ATTRIBUTE_TO_ARRAY_WITH_FIX_VALUE
2.8 LENGTH Function
2.9 NOW Function ( Current Date with Pattern )
2.10 DATE FORMAT Function ( to format the date )
2.11 RANDOM Function
2.12 PADRIGHTSTRING Function
2.13 PADLEFTSTRING Function
2.14 STRIPSTART Function
2.15 DIFFTIMESTAMP Function
2.16 RIGHTSTRING Function
2.17 SUBSTRING Function
2.18 SUBSTRING BETWEEN Function
2.19 TIMESTAMP Function
2.20 UTC Time Function
2.21 Concatenate Function
2.22 GLU SERVER NAME
2.23 GLU TRX ID
2.24 GLU REDELIVERY COUNTER
2.25 ADD DAYS TO DATE Function
2.26 REMOVE DAYS TO DATE Function
2.27 DIFFERENCE_BETWEEN_DATES Function
2.28 SET_DATA_TO_CACHE
2.29 GET DATA FROM CACHE
2.30 GET DATA FROM CACHE CONTAINS
2.31 GET MAPPED ARRAY FROM CACHE
2.32 CREATE_ARRAY
2.33 CREATE_ARRAYS_FROM_STRING_WITH_ATTRIBUTES
2.34 REPLACE
2.35 ENCODESTRING
2.36 DECODESTRING
2.37 ADD / REMOVE PERIOD
2.38 ENCRYPT USING RSA PUBLIC KEY
2.39 CONVERT DATE TO TIMESTAMP
2.40 MERGE_VALUES_IN_ARRAY
2.41 HMAC SHA 1 Encoder
2.42 HMAC SHA 256 Encoder
2.43 AES 256 Encryption (CBC)
2.44 AES 256 Decryption (CBC)
2.45 BASE64_TO_HEX
2.46 MD5 HEX HASH
2.47 URL_ENCODER
2.48 Consolidate
2.49 toLowerCase
2.50 toUpperCase
2.51 mod
2.52 XML Signatures
2.53 SIGN_MX_MESSAGE
2.54 VERIFY_MX_MESSAGE
2.55 JSON Web Signature (JWS) or JSON Web Encryption (JWE)
2.56 GENERATE_FINGERPRINT
2.57 ENCODE_HEX_TO_BASE64
2.58 GENERATE_JWS
2.59 GET_BODY()
2.60 GET_VALUE_FROM_JSON_PAYLOAD()
2.61 GET_ATTRBUTE_VALUE_FROM_ARRAY_BY_INDEX
2.62 CREATE_ARRAY_FROM_ARRAY_AND_ARRAY_CHILDREN
2.63 AES GCM Decryption
2.64 Luhn Algorithm
3 Customer Specific Functions
3.1 PAN_ENCRYPT
GLU Formulas

Using Handlers

Handlers enable business rules/logic to be applied to the flow and based on those rules the transaction flow can take different paths or actions that can be triggered in the flows to ultimately conclude with the ‘Response’ to the Initiating System.

Handlers can be added to any Inbound API Request or Response or any downstream system Response.

  • A Handler on an Inbound API Request could for example trigger the routing of the request to another Inbound API on the same GLU.Engine.See here for more: Redirect to other transactions
  • A Handler on an Inbound API Response could for example trigger the flow to be re-routed or it could trigger a param matching a certain value to trigger it to be over-written etc.
  • A Handler on the Response to an outbound Connector call is the most widely used mechanism for orchestrating your flows.

Handlers enable business rules/logic to be applied to the flow and based on those rules the transaction flow can take different paths to ultimately conclude with the ‘Response’ to the Initiating System. A Request Handler can allow multiple transactions or actions to be accessed from one API request. Request Handlers can be configured based on Request Parameter Content or for Request Conditions:

Generate Parameters from a Template

Load Template to Generate Parameters

Within the ‘Parameters Manager Control Panel’ for any Request or Response configuration find the ‘Load Template to Generate Parameters’ tool.

Clicking this tool opens up a pop-up box into which you can paste the template for the payload. The ‘Content Type’ that you have specified for the Request or Response in the ‘Request / Response Manager Control Panel’ will determine the template format that you will need to paste e.g. JSON or XML format.

The ‘Add Only New Parameters’ checkbox enables you to avoid duplicating auto-generated parameters when making updates to the template you are loading.

The ‘Path Not Included’ checkbox inform GLU to ignore the missing path if it’s missing from the template.

When pasting your template, check it’s formatted correctly by clicking on the ‘Format’ button, make any corrections needed.

Thereafter you by clicking on ‘Generate Parameters’, GLU will auto-create all parameters in the Template within the applicable Request / Response Parameter set. Additionally the ‘collection path’ for each parameter is auto-populated. This is tremendously useful especially when the template has a ‘deep’ tree structure.

This feature provides the most efficient mechanism to quickly generate Request and Response payloads. We recommend that you use ‘working’ sample test message templates too (as often sample templates in API specifications are not 100% correct).

Parameter Validation

Validation rules can be created for

  • Parameters that are passed to APIs as inbound API parameters (request Parameters)
  • Response Parameters from Connectors in Orchestration (response Parameters)

Depending on the type of parameter, various types of validation are available.

Hash is described in a separate section of the User Guide.

Min/Max Length

This refers to the character length of Text and the number of digits for an Integer or Float.

If the min Length is left null then only the max length will apply.

If the max Length is left null then only the min length will apply.

Example 01

For the configuration of Min = 2 & Max = 4;

A string of “hello world” would fail this validation as the number of characters are greater than 4 and not equal to 4.

A string of “h” would fail this validation as the number of characters is less than 2 and not equal to 2.

A string of “hell” would pass this validation as the number of characters is greater than 2 and less than 4.

An Integer of 232 would pass this validation as the number of characters is greater than 2 and less than 4.

An Integer of 23 would pass this validation as the number of characters is equal to 2.

An Integer of 2324 would pass this validation as the number of characters is equal to 4.

Example 02

You could do a validation on the length of an incoming parameter, so as to then route to a specific action based on the length.

To do so, you can create a Derived Parameter to calculate length then add a Handler to route based on the Derived Parameter value (i.e. length).

In this case, the Derived Parameter formula might look like this: ${token_num}.length()

Min/Max Value

This refers to the paramters value.

If the min Value is left null then only the max Value will apply.

If the max Value is left null then only the min Value will apply.

Example

For the configuration of Min = 2 & Max = 4;

An integer of “27” would fail this validation as the value is greater than 4 and not equal to 4.

An integer of “1” would fail this validation as the value is less than 2 and not equal to 2.

An integer of “3” would pass this validation as the value is greater than 2 and less than 4.

An integer of “2” would pass this validation as the value is equal to 2.

An integer of “4” would pass this validation as the value is equal to 4.

Regex

Regex format validation can be applied by putting the regular expression into the regex field.

Use this link to see a cheat sheet of common regular expressions.

Use this link to try out the regular expressions prior to configuring in the validation of the parameter.

Example 01

For the configuration of RegEx (Alpha Only): [a-zA-Z]*

A string of “hello_world” would fail this validation as the string contains a special character.

A string of “hello2” would fail this validation as the string contains a number.

A string of “helloWorld” would pass this validation as the string contains only letters ( Alpha Only).

Date Format

The format field should be used to set the format the date will need to be passed to the parameter in.

If the date format was set to dd-mm-yyyy

if 23-OCT-2019 was passed in as a date, it would not pass the validation and an error would be raised.

of 23-10-2019 was passed in as a date then this would pass validation.

Date formats are defined by ISO 8601

Recommended date format

2012-04-23T18:25:43.511Z

It is recommended to ensure date formats used

  • are human-readable but also succinct
  • sorts correctly
  • includes fractional seconds which can help re-establish chronology
  • conforms to ISO 8601

For a more detailed view on date formatting please refer to Date type formatting

Image

For an image parameter, if the default value is set, then if an image base64 value is not passed into the parameter then the default base64 value will be used.

This base64 image decoder can be used to extract a base64 image string.

Default

All datatypes have a default value field which can be set if the parameter is passed in with out a value set.

The default value needs to adhere to the data type it configures and needs to adhere to the validation rules applied.

Required

All Validation rules have the Boolean option to indicate if the field is required or not.

If the Required checkbox is ticked then default values can not be entered.

If required and a parameter is not provided then the validation will fail.

Masking Sensitive Data/Parameters in Logs

Parameters in your messages at times may be sensitive such that presenting these values in the logs is a security risk. GLU.Engines generate two types of logs where values need to be controlled –

1) Where Parameters are included in the ‘PAYLOAD’ and

2) Where Parameters are printed in the log as ‘PARAM’.

Masking sensitive data can be controlled for log entries.

PAYLOAD Log Masking is controlled at the Transaction Level.

PARAM Log Masking is controlled at the Parameter configuration level.

NOTE: Payload masks only mask Parameters in Payload when printed in Log. The Payload mask does not mask the value when it is unmarshalled. To mask values when unmarshalled add a mask for the full String as it prints in the logs. Parameter masks the values when unmarshalled.

To mask PAYLOAD values, at the ‘Transaction’ level, within the Transaction Manager Panel, use the ‘Mask PAYLOAD Values in Logs’ field to define the ‘tags’ for any values that need to be masked along with the GLU reserved word “GLU_MASK” (e.g. “username”:”GLU_MASK”) which will replace the value for username with “**********”.

Since tags are used, any payload value can be masked i.e. not just the parameter values within the payload. Tags to be masked can be copied from your payload template configuration and will vary depending on the type of payload (XML, JSON, SQL call, etc.).

NOTE: the GLU_MASK value used is the full line, so if you complete the line entry with “username”: “GLU_MASK”, – the value will also be included in the masking of username – e.g. “**********”

To mask PARAM values, the ‘Mask PARAM Value in Logs’ checkbox (which by default is ‘checked’) must be unchecked.

Any payload tag (PAYLOAD logs) or parameter name (PARAM logs) that is configured to be masked will be masked in in all logs (INFO, WARN, DEBUG etc.) for all logs associated with a particular transaction.

Pass Last Response Content Back

Passes connector response back to API request, no unmarshalling or data validation/enrichment is done. Whatever is received is passed. Removes the need for a success response template.

Note: In order to use this feature, first select the Content Type (e.g. JSON) then check the box. We have a roadmap feature to prevent the box from being checked before the Content Type is selected. If this happens, the ‘Content Type’ field is removed resulting in a ‘NULL’ value Response.

Types of Parameters

Simple Parameter – one-to-one parameter mapping of an attribute that is not related to an Object and is not part of a List or Array.

Simple List of Parameters – a List or Array of parameters.

Complex List of Parameters – a list or lists within a List or Array.

For a Simple Parameter, using the JSON sample Request, in order to handle the ‘created_by’ parameter, we’ll look for ‘created_by’ from the example body below. It is highlighted in green. The UnMarshalling for this parameter should willhave only need the Parameter Name as received to be set to ‘created_by’ and the location it should be retrieved from being the ‘- Body’ in this case (alternatives being the , Header or Query). The Parameter Properties can be used to change the Parameter Name if required. In this example, GLU receives ‘created_by’ and the Parameter is saved as ‘creator’

Note: Object / Collection Path and Value Map are not required in this example because this ‘Simple Parameter’ is located at the base level of the message body i.e. it is not embedded within the a tree structure within the message. .

For a more deeply embedded Simple Parameter example, let’s look at the ‘would_seek_employment’ parameter, highlighted in red. The resultant Object / Collection Path for this parameter would look like this:

household_members[].skills_employment_and_small_business.employment_options With the parameter name we’re looking for, ‘would_seek_employment’ is noted as Parameter Name.

This parameter is in an Attribute of the Object ‘skills_employment_and_small_business.empolyment_options’, which is in the ‘household_members’ array. For the GLU UnMarshalling for this parameter, we need to look into the array. T- the array is denoted by the square brackets ‘[]’, as if you were reading from the JSON request. Then the Object needs to be specified. It is separated from the Array name by a full-stop ‘.’.

This example also has a Value Map: GLU will substitute the first value with the second i.e. if the received value is ‘true’, GLU will store ‘yes’ (an empty value also can be mapped by replacing the first value with space [ ,Empty] ). This enables GLU to transform parameter values on the fly based on the Value Map settings.

Once UnMarshalled, the Parameter Properties can be used to change the Parameter Name from ‘would_seek_employment’ to ‘lookingForWork’. We can also change the Array and Object names- in this example, these have been changed to ‘members’ and ‘skills_employment.employment_status’ respectively:

In this example, input: “would_seek_employment”: “true” would save as “lookingForWork”: “yes”

For a Simple List of Parameters, we’ll look for ‘family_name’ from the example body below. It is highlighted in blue.

This is a Parameter than is sent in an Array. T- there can be many instances of the same parameter in the Array.

We need to look into the ‘household_members’ Array to find ‘family_name’ – with the Object / Collection Path specified as an Array, using square brackets, ‘[]’, we know that more than one parameter with this name can be present in the Array.

The Parameter can then be saved with the same or a new Parameter Name or Array name- in the below example, the Parameter Name has changed to ‘surname’ and the Array to ‘members’. The received array or ‘family_name’ from ‘household_members’ Array will now show under ‘members’ Array as ‘surname’.

For the Complex List of Parameters, we’ll look for ‘lThumb’. It is highlighted in purple.

Here we have a Parameter, ‘lThumb’ that is in an Array (represented in the JSON file by the [] square brackets), “raw_image_data” which is in an Object Collection (represented in the JSON by the {} curly brackets), “biometrics” which is in an Array (square [] brackets), “household_members”.

The Object / Collection Path shows the logic to collect these parameters: household_members[].biometrics.raw_image_data[] That’s: Array[].Object.Array[] with the target Parameter Name of ‘lThumb’

Parameters Types and Configurations

General Principles of Parameters

Parameter Names must be unique in the GLU Object Model – i.e. when you unmarshal them. It doesn’t matter if two or more parameters reside in different places in a message payload e.g. at different levels of a tree of nested arrays. Thus when using the ‘Generate Parameters from Template’ tool it may be that the template has parameters that have the same names. In this case or if you manually create parameter names in the GLU Object Model that are duplicates, the Console Validations will show these duplicates as ‘Warnings’ which you will need to resolve.

Derived Parameters

A Derived Parameter can apply a Formula or a Function to another Parameter or Parameters. Derived Parameters can be defined on both Inbound Requests and Outbound Responses.

In the example screenshot below, the formula takes an existing Parameter ‘interestRate’ and multiplies it by 100.

This would take an input value of ‘0.06’ and work out a new value of ‘6’. The new calculated Parameter needs to be given a new, different name to the input parameter(s). In other words, the example could be called ‘multipliedInterestRate’ but not ‘interestRate’.

Common Name

The ‘Common Name’ format can include spaces and special characters if desired since it’s not used within the GLU.Engine.

Time Parameters

You are able to capture the timestamp to record the specific point in time when a Request / Response messages are sent or received by the GLU.Engine – for this use the ‘Response Time Parameter’ (Inbound Response and Outbound Response) or the ‘Submit Time Parameter’ (Outbound Request).

The Response Time Parameter can be created on the response handler control panel. This parameter can then be referenced in the response template. The parameter can be added in the parameter list referencing the parameter name created and the date and time format of this can be defined in the marshaling panel of this parameter.

Request Parameters

For each Parameter being received, the ‘Parameter Manager Panel’ is used to define various characteristic of the Parameter as well has how each Parameter must be handled by the GLU.Engine. Use the ‘Add Parameters’ button under the ‘Parameters Panel’ to add Parameters for the applicable Request.

See the next major section for details on Parameter Types and Validation Rules.

One can also define ‘Validation’ rules for each Parameter that can be used to protect downstream systems from inbound messages that don’t pass the defined validation rules. Thus, the GLU.Engine can provide a layer of load/performance protection to downstream Receiving Systems.

When a Parameter doesn’t meet pass the Validation Rules, an error message is displayed citing the Parameter and the Rule broken. EG: textLength less than Min length Depending on the Parameter ‘Type’ being received there are different Parameter Validation Rules as described below.

General Parameter Configuration Settings

Make Visible in logs’ – Indicates that the Parameter will be included in the gluware.log. If un-checked, the Parameter will not be visible in the logs. · ‘Min / Max Length’ – used to decline the number of characters allowed for that Parameter. · ‘Min / Max Value’ – used to define the min / max allowed. · ‘Regex’ – gives an option to add a Regular Expression validator (resources such as regextester that can help to define your Regex). · ‘Default’ – is used to add the value at the GLU.Engine layer rather than it being received from the ‘Initiating System’.

Parameter Type

Text

‘Text’ type Parameters are simple alpha characters only. The validation configuration options are as follows: · ‘Required’ – Indicates that the Parameter must be received. If it is not received then the GLU.Engine responds by stopping the transaction from progressing and returning a ‘parameter required’ response to the initiating system, the logs likewise will reflect the same. · ‘Make Visible in logs’ – Indicates that the Parameter will be included in the gluware.log. If un-checked, the Parameter will not be visible in the logs.@Jono: Check if this is true · ‘Min / Max Length’ – used to define the number of characters allowed for that Parameter. · ‘Regex’ – gives an option to add a Regular Expression validator (resources such as[ |https://www.regextester.com/]{+}https://www.regextester.com/+ can help to define your Regex). · ‘Default’ – is used to add a value at the GLU.Engine layer. If it’s received, the GLU.Engine will pass the received value, if not received, the GLU.Engine passes the default.

Image

Images can be received as Parameters in the form of an encoded object (e.g. Base64), in this case one can stipulate that the Parameter is ‘Required’ using the check-box or a ‘Default’ value can be assigned. The ‘Default’ value is used for situations where the Image is being added at the GLU.Engine layer rather than it being received from the ‘Initiating System’. The encoded object can be passed regardless of the format (JSON or XML) being used.

Float

A ‘Float’ type Parameter is a numeral, potentially with decimals as might be the case for a monetary value. The validation configuration options are as follows: · ‘Required’ – Indicates that the Parameter must be received.

Integer

An ‘Integer’ type Parameter is a whole number with no fractions or decimals. The validation configuration options are as follows: · ‘Required’ – Indicates that the Parameter must be received. · ‘Make Visible in logs’ – Indicates that the Parameter will be included in the gluware.log. If un-checked, the Parameter will not be visible in the logs. · ‘Min / Max Length’ – used to define the number of characters allowed for that Parameter. · ‘Min / Max Value’ – used to define the min/max allowed. · ‘Regex’ – gives an option to add a Regular Expression validator (resources such as[ |https://www.regextester.com/]{+}https://www.regextester.com/+ can help to define your Regex). · ‘Default’ – is used to add the value at the GLU.Engine layer rather than it being received from the ‘Initiating System

Hash

A ‘Hash’ type Parameter is a secure value. A secure Hash Algorithm, also known as a SHA, is a cryptographic function designed to keep data secured. It works by transforming specified input data using a hash function. The hash function produces a fixed size string that looks nothing like the input. These algorithms are designed to be one-way functions, meaning that once they’re transformed into their respective hash values, it’s virtually impossible to transform them back into the original data. One can use a SHA to encrypt sensitive Parameters such as passwords, so the server only needs to keep the specific user’s hash value, not the actual password. Any breach of the database will find only the hashed values and not the actual passwords.


SHAs can also be used to detect the tampering of data by attackers, preventing “Man in the Middle” attacks.


GLU.Ware supports SHA-1SHA-256SHA-384 and SHA-512 as well as the older MD5 verification.


The higher the SHA option selected the more secure but also the higher the system processing load will be. This can be configured with select or all parameters in a request or a response to ensure its authenticity.

NOTE: MD5 and SHA-1 Hash Algorithms have both been compromised and should not be used.

GLU continues to support these Hash options as we understand that some systems do still use them and may not change. The risk of doing so is entirely for the Customer / User of GLU.Ware.


The SHA uses data from the message, which it validates as input to the Hash Algorithm. For example, a request with parameters “accountID”, “amount” and “reference” can be configured to use a single parameter or all parameters as input to the Hash Algorithm.


The input parameters are specified in the Hash Expression. To use “accountID” and “amount” from the example above, the expression should be set to: ${accountID}+${amount} A Salt Key can also be inserted for additional safeguarding. The salt value provides an external input to the Hash that isn’t present in the message being validated. The Salt Key and the Hash Type being used must be shared with the Receiving System to ensure that it has the same inputs to the SHA. The Salt Key can be any random value. The ‘Create Hash’ flag: If not checked, the GLU.Engine will pass what is received from the ‘Initiating System’. If checked, the GLU.Engine will generate then pass the hash (using expression).


If the ‘Create Hash’ is not checked, a ‘Default’ value can also be set such that if the ‘Initiating System’ fails to send a value, the ‘Default’ value will be used.

Date

‘Date’ parameter type must be used when you are handling dates or times in your GLU engine. Functions such as NOW() and DIFFTIMESTAMP() require the parameters to be of a date type.

In order to save the value into a date type, you need to set the unmarshalling date format to ensure the engine is able to read the date correctly.

Example: If you receive a date in the format of 2020-10-21 15:10:03, you can configure the unmarshalling panel as below.

Example with timezone: 20201021T13:25:04+0330 then the unmarshalling panel would have: yyyyMMdd’T’HH:mm:ssZ

  "ResponseAsTime1": "2022-03-11 11:12:49:1249",
  "RequestAsTime2 G-yy-MMMM-w-W-D-E-u-a-k-h-z-Z-X": "AD-22-March-11-2-70-Fri-5-AM-11-11-GMT-+0000-Z"


The following table defined the syntax to use, with locale being set to match the language which the GLU.Engine was initiated with (see XX).

Also note the following additional Letters for Pattern

– ms gives microseconds to the thousands of a second. See example below

  "ResponseAsTime1": "2022-03-11 11:12:49:1249",
  "RequestAsTime2 G-yy-MMMM-w-W-D-E-u-a-k-h-ms": "AD-22-March-11-2-70-Fri-5-AM-11-1249"

Example 1: format: E dd MMM yyyy HH:mm:ss z output: Thu 09 Jun 2022 10:10:06 CAT

Outbound Date Marshalling

When completing outbound marshalling, you can set a date parameter to hold a specific format by using the Date Format in the marshalling panel.

Example: 2020-10-21T13:25:04 then the marshalling date format will be: yyyy-MM-dd’T’HH:mm:ss

Reserved Words

The following words are reserved words.

This means they can only be used for the relevant command defined below They can not be used as variable names in Public Static Collection NameAuthentication Parameter Control Nametransaction nameflow code or parameter name.

Validation has been put in place in the Integration Builder to check if these reserved words are used in the wrong place.

To protect for reserved words, if a reserved word is added it is automatically removed by the screen once it sees the word. The example below shows how it is not possible to add the “n” on “join” as it is a reserved word.

The reserved word GLU_STATUS_CODE can be used to pass the last status code from a third party ( more details on the Response Manager page. http://www.guide.glu.global/Response_Manager )

The list of GLU Reserved Word

  • concat
    • copyWithin
    • dateTimeNOW
    • entries
    • every
    • GLU_schemaName
    • fill
    • filter
    • find
    • findIndex
    • forEach
    • from
    • Header
    • includes
    • indexOf
    • isArray
    • join
    • keys
    • lastIndexOf
    • length
    • map
    • null
    • pop
    • push
    • reduce
    • reduceRight
    • reverse
    • shift
    • slice
    • split
    • some
    • sort
    • splice
    • toString
    • unshift
    • values
    Fill the form and we’ll contact you shortly

      I agree with

      cookies
      We uses cookies to make your experience on this website better. Learn more
      Accept cookies