Gloop Design Guidelines
Gloop naming conventions follow closely the Java naming conventions.
|Integrate Packages||Integrate package names should be nouns in mixed case with the first letter of each internal word capitalized. It should be simple and descriptive.||MyIntegration|
|Code Packages||Code package names should be all-lowercase. Commonly the first package is one of the top-level domain names.||com.company.integration|
|Gloop Files||Gloop file1 names should be nouns or verbs in mixed case with the first letter of each internal word capitalized. It should be simple and descriptive.||MyGloopService, UpdateAccount, GetRemoteData|
|Gloop Properties||Gloop property (or variable) names are in mixed lowercase, internal words start with capital letters. It should not be any of the Java, Groovy or Gloop keywords.||url, person, accountName|
List of Gloop keywords that should not be used for naming:
$gloopIndexUsed in Iterate and While steps
$gloopCountUsed in Iterate and While steps
$gloopIterateUsed in Break step
$gloopWhileUsed in Break step
$gloopParentUsed in Break step
$gloopServiceUsed in Break step
$gloopAllUsed in Break step
$gloopExceptionUsed in Block catch step
$gloopOutputUsed in Invoke steps
Gloop Files Organization
All the Gloop files1 should be located under the code directory of an Integrate Package. It is advised to organize the files per feature rather can per file type.
Example of a bad file organization:
1 2 3 4 5 6 7 8 9 10 11
MyIntegration code com.company sql CreateAccount.gloop DeleteAccount.gloop CreateContact.gloop DeleteContact.gloop flatfile ExportAccount.ffd ExportContact.ffd
Example of a good file organization:
1 2 3 4 5 6 7 8 9 10 11
MyIntegration code com.company account CreateAccount.gloop DeleteAccount.gloop ExportAccount.ffd contact CreateContact.gloop DeleteContact.gloop ExportContact.ffd
By default handling of exceptions is optional in Gloop, if a service throws an exception and is not caught it will be propagated outside of the service. It is often preferable to handle the exception and provide a remedy to the error or a useful message explaining why the error occurred. It is specially true when a service is exposed via REST or SOAP API.
Separation of Concerns
In most cases a Gloop service should only have one function or purpose.
For example let's consider services to delete entities, a bad example would be the following:
com.company.Delete( type, entity ) // e.g. com.company.Delete( 'account', account )
A better example would be to breakdown the functionality into multiple services:
com.company.account.DeleteAccount( account ) com.company.contact.DeleteContact( contact )