Terminology
This topic provides information about basic concepts associated with job execution and access-control management.
Job | A job is a task or a sequence of tasks that will be executed by the server. A job consists of the following parts (some of them are optional): input parameters, execution steps, triggers, credentials and various settings.
The degree of complexity of a job can vary, depending on your business needs and requirements. A job can consist of one step (e.g., performing a MapForce transformation) or can be configured to perform multiple actions (e.g., creating a directory listing and sending it by email). For details about job configuration, see Job Configuration.
|
Job instance | A job instance is not the same as a job. When you configure a FlowForce job on the job configuration page, you create in fact a job configuration. Every time the defined trigger criteria for a job apply, an instance of the job starts running. Every job instance has an execution result that can be successful, failed, or interrupted/unknown. For details, see Statistics.
|
Trigger | When you create a job, you must specify conditions that will start the job. These conditions are known as triggers.
FlowForce Server continuously checks for trigger conditions and executes jobs whenever specific trigger conditions are met. A job can have multiple triggers. You can enable and disable triggers when necessary.
|
Step | In FlowForce Server, steps define what a job must do (e.g., delete a file, execute a MapForce mapping, send an email). In its simplest form, a step is an operation with failed or successful outcome. Each step must execute a step function. You can create as many steps as required for your job and set the order in which the steps must be executed. You can also use the result of a step in other steps.
To find out more about steps, see Job Execution Steps.
|
Function | In FlowForce Server, there are two types of functions: (i) step functions and (ii) expression functions.
A step function defines a particular operation to be performed. Each execution step must have a step function. For example, the system/mail/send function instructs FlowForce Server to send an email to the specified recipients. The following types of step functions are available:
•A job as an execution step of another job
Most step functions have parameters. Parameters can accept different values, including expressions and expression functions. Expression functions manipulate values supplied as arguments, for example, to join strings (see the concat function). For an example of a job that uses expression functions, see Example 2 in the send-mime function.
|
Step result | The result of a step defines what is returned after the step has been executed (e.g., a file). You can use the step result in other execution steps. See Example 1 in the send-mime function, in which the result of the second step is used in the Message body parameter of the last step.
For more information about step results, see Step Result.
|
Execution result | FlowForce Server enables you to declare the return type of a job. You must specify the return type of a job if you want to cache the job result. Declaring the return type of a job result is also meaningful if you intend to process the return value of this job in another job.
For more information, see Execution Result.
|
Credential | A credential object is a piece of data that stores authentication information such as usernames and passwords, certificates, API keys, tokens, etc. that are used to securely manage and transmit authentication details and access different services and resources.
For more information about credentials, see Credentials.
|
Container | FlowForce Server manages jobs, credentials, step functions, and other configuration objects in a hierarchical structure of containers. A container is similar to a folder on an operating system. Containers can have any of the following: jobs, credentials, functions, and other containers. By setting permissions on a container, you can control who can access the container's contents.
|
User | A user is a person who logs on to FlowForce Server to create and monitor jobs, deploy MapForce mappings and StyleVision transformations, and configure various settings. The scope of actions available to users in FlowForce Server depends on the following:
•The permissions and privileges assigned to the users •The permissions and privileges assigned to the roles that the users are members of
|
Role | A role defines a set of privileges and permissions. It can be assigned to another role or to a user. A role's privileges automatically become the privileges of any other role or any user that the role is assigned to. A user can be assigned any number of roles. As a result, a user will have all the privileges defined in the multiple assigned roles.
Note that privileges are global, whereas permissions are defined per container.
|
Privilege | A privilege is an activity that a user is allowed to carry out (e.g., set a password, read users and roles, stop any job, etc.). A user can be assigned zero to all of the available privileges. It is recommended to assign privileges via roles rather than to assign privileges directly to the user. The assigning of privileges and roles to a user is done by a user that has been assigned this privilege. Initially, it is the root user that has this privilege.
|
Permission | Permissions are access rights and can be set for each container individually. Permissions determine which users or roles have access to that container and what kind of access each user/role has (read, write, use, no access). Permissions can be defined for containers, configuration objects, credentials, queues, services, functions, resources, and child containers. In FlowForce Server Advanced Edition, permissions can also be set for certificates and AS2 partner objects.
|
Password policy | A password policy defines a set of minimum requirements that a user password must meet in order to be valid (e.g., a password must be at least N characters long). FlowForce Servers uses password policies to enable administrators to enforce the complexity of user passwords.
|