Business logic object designs
As a developer, you can use the information in this topic for business logic object designs, their standard formats, and guidelines.
When an active link is executed, it triggers varying actions as the result of a single user action. When you design an active link, you specify the conditions under which the active link executes, and further conditions to determine which action it will take.
Depending on the purpose of an active link, there are guidelines for designing and naming them. For information about the purpose of active links, see Workflow objects.
Active link names
The standard format for the name of an active link is as follows:
System Code:[Form Code]:[Field/Button/Guide
Name]Description[###]_[Operational Description]
Square brackets denote optional parts of the name. See the following table for definitions of the parameters in the name.
Active link name format
Parameter | Definition |
---|---|
System Code | A code that contains two to six uppercase letters. |
Form Code | The actual form code. If the active link is shared, use SHR. Although the form code is optional, use it consistently within systems and a set of applications. |
Field/Button/Guide Name | (Optional) An associated field name, button name, or guide name, if applicable. |
Description | A brief functional description of the workflow performed. Use camelCase notation and no space between words. |
### | (Optional) A sequence order if an active link is part of a series. Use three digits. Allow some gaps in the sequence order for expansion; for example, 010, 020, 030. The sequence order is different from the execution order number, which is not included in the name. |
Operational Description | (Optional) A free-form description. Establish standards within applications and across a set of applications. Some common operations are Initialize, Validate, Message, Process, Get, Set, Modify, Delete, Submit, and CallGuide; for examples, ValidateRequestID and CheckDuplicate. |
Integration-specific active link names
Integration active links exist between two systems, one of which is not part of the Foundation module. These active links are not required in either of the two stand-alone systems.
These active links are named to belong in an integration system identified by the INT integration system code and the system link code, which consists of combining both systems codes for the integration in alphabetical order.
Naming convention for integration-specific active links
The standard format for the name of an integration-specific active link is as follows:
INT:System Link Code:[Form Code]:[Field/Button/Guide
Name]Description[###]_[Operational Description]
Active links that perform preparation workflow for the integration and are not required in the stand-alone applications are also part of the INT system and use the system code of the system in which they were created. These active links might be used in several integrations and will be loaded for all integrations that contain a matching system in the system link code.
Naming convention for integration-preparation active links
The standard format for the name of an integration-preparation active link is as follows:
INT:System Code:[Form Code]:[Field/Button/Guide
Name]Description[###]_[Operational Description]
Shared active link names
Active links shared within and across the Foundation module and applications have a SHR: system code and a SHR: form code.
Naming convention for shared active links
The standard format for the name of a shared active link is as follows:
SHR:SHR:[Field/Button/Guide Name]Description[###]_[Operational Description]
A filter tests every request transaction to see if certain conditions are met, and then responds to the conditions by taking specific actions. This section provides guidelines for designing filters. For information about the purpose of filters, see Workflow objects.
Filter names
The standard format for the name of a filter is as follows:
System Code:[Form Code]:[Guide Name]Description[###]_[Operational Description]
Square brackets denote optional parts of the name. See the following table for definitions of the parameters in the name.
Filter name format
Parameter | Definition |
---|---|
System Code | A code that contains two to six uppercase letters. |
Form Code | The actual form code. If the active link is shared, use SHR. Although the form code is optional, use it consistently within systems and a set of applications. |
Guide Name | (Optional) an associated guide name, if applicable. |
Description | A brief functional description of the workflow performed. Use camelCase notation and no spaces between words. |
### | Optional sequence order if the filter is part of a series. Use three digits. Allow some gaps in the sequence order for expansion (for example, 010, 020, 030). The sequence order is not the same as the execution order number, which should not be included in the name. |
Operational Description | (Optional) A free-form description. Establish standards within applications and across a set of applications. Some common operations are Initialize, Validate, Message, Process, Get, Set, Modify, Delete, Submit, and CallGuide; for examples, ValidateRequestID and CheckDuplicate. |
Integration-specific filter names
Integration filters are those that exist between two systems, one of which is not part of the Foundation module. These filters are not required in either of the two stand-alone systems. These filters are named to belong in an integration system identified by the INT integration system code and the system link code, which consists of combining (in alphabetical order) both system codes for the integration.
Naming convention for integration-specific filters
The standard format for the name of an integration-specific filter is as follows:
INT:System Link Code:[Form Code]:[Guide Name]Description[###]_[Operational
Description]
Filters that perform preparation workflow for the integration and are not required in the stand-alone applications are also part of the INT system and use the system code of the system in which they were created. Such filters might be used in several integrations and are loaded for all integrations that contain a matching system in the system link code.
Naming convention for integration-preparation filters
The standard format for the name of an integration-preparation filter is as follows:
INT:System Code:[Form Code]:[Guide Name]Description[###]_[Operational Description]
Shared filter names
Filters shared within and across the Foundation module and other applications have a SHR: system code and a SHR: form code.
Naming convention for shared filters
The standard format for the name of a shared filter is as follows:
SHR:SHR:[Guide Name]Description[###]_[Operational Description]
Execution order
The following table specifies reserved filter execution orders:
Filter execution order ranges
Execution order range | Filter function or action |
---|---|
000 – 025 | Reserved for Goto filters |
800 – 899 | Reserved for Notification filters |
900 – 990 | Reserved for Audit filters |
990 – 999 | Reserved for Goto filters |
You should stagger execution orders between the range of 026 – 799, allowing some gaps within blocks of code so that it is possible to add a new workflow if needed.
Filter Help text
Help text is a requirement. Always complete the Help text field found in the Help text tab of the filter. Ensure that the Help text is informative for other developers as well as the administrator, and include details if it is part of a workflow sequence.
Business objects, such as filters, active links, and escalations can be grouped into guides to control the order of processing. The guidelines for designing guides are provided here and for more information about the purpose of guides, see Creating guides.
Guide names
The standard format for the name of a guide is as follows:
System Code:[Form Code]:Description
Square brackets denote optional parts of the name. See the following table for definitions of the parameters in the name.
Guide name format
Parameter | Definition |
---|---|
System Code | A code that contains two to six uppercase letters |
Form Code | The actual form code. If the active link is shared, use SHR. Although the form code is optional, use it consistently within systems and a set of applications. |
Description | A brief functional description of the workflow performed. Use camelCase notation and no space between words. |
Integration-specific guide names
Integration guides are those that exist between two systems, one of which is not part of the Foundation module. Such guides are not required in either of the two stand-alone systems. These guides are named to belong in an integration system identified by the INT integration system code and the system link code, which consists of combining in alphabetical order both systems codes for the integration.
Naming convention for integration-specific guides
The standard format for the name of an integration-specific guide is as follows:
INT:System Link Code:[Form Code]:Description
Guides that contain preparation workflow for the integration and are not required in the stand-alone application are also part of the INT system and use the system code of the system in which they were created. Such guides might be used in several integrations and are loaded for all integrations that contain a matching system in the system link code.
Naming convention for integration-preparation guides
The standard format for the name of an integration-preparation guide is as follows:
INT:System Code:[Form Code]:Description
Shared guide names
Guides shared within and across the Foundation module and other applications have a SHR: system code and a SHR: form code.
Naming convention for shared guides
The standard format for the name of a shared guide is as follows:
SHR:SHR:Description
Escalation causes a condition to be checked on a regular basis and, depending on whether and how the condition is met, performs one or more actions. Escalations can be assigned to pools so the escalations from each pool run in parallel on separate threads within the escalation queue. The guidelines for designing escalations are provided here and for more information about the purpose of escalations, see Workflow objects.
Escalation names
An escalation starts on all records that match the qualification criteria assigned to it. If an escalation is meant to start only once at the specified interval or time, ensure that no more than one record matches the qualification criteria. The standard format for the name of an escalation is as follows:
System Code:[Form Code]:Description
Square brackets denote optional parts of the name. See the following table for definitions of the parameters in the name.
Escalation name format
Parameter | Definition |
---|---|
System Code | A code that contains two to six uppercase letters |
Form Code | The actual form code. If the active link is shared, use SHR. Although the form code is optional, use it consistently within systems and a set of applications. |
Description | A brief functional description of the workflow performed. Use camelCase notation and no space between words. |
Integration-specific escalation names
Integration escalations are those that exist between two systems, one of which is not part of the Foundation module. These escalations are not required in either of the two stand-alone systems. These escalations are named to belong in an integration system identified by the INT integration system code and the system link code, which consists of combining in alphabetical order both systems codes for the integration.
Naming convention for integration-specific escalations
The standard format for the name of an integration-specific escalation is as follows:
INT:System Link Code:[Form Code]:Description
Escalations that perform preparation workflow for the integration and are not required in the stand-alone applications are also part of the INT system and use the system code of the system in which they were created. These escalations might be used in several integrations and are loaded for all integrations that contain a matching system in the system link code.
Naming convention for integration-preparation escalations
The standard format for the name of an integration-preparation escalation is as follows:
INT:System Code:[Form Code]:Description
Shared escalation names
Escalations shared within and across the Foundation module and applications have a SHR: system code and a SHR: form code.
Naming convention for shared escalations
The standard format for the name of a shared escalation is as follows:
SHR:SHR:Description
For information about defining service actions for active links, filters, and escalations, see Defining Service actions to trigger services based on conditions.