Jobs are available for Oracle-based enterprise industry models only. Jobs provide a long transaction and versioning framework. Jobs make it possible to have multiple states for an object in the database.
You can change data only within a job. Data outside a job is read-only, and is equivalent to the Live data within a job.
Open — Once data modification is initiated, the job is set to open. Data changes are isolated within that job and are not visible in other jobs or outside jobs. Feature locking is either Pessimistic or Optimistic.
Pending — When changes are ready for review and approval, the job (including all altered data) is set to Pending. Data changes are visible in all open and pending jobs. The changes can be still be reverted.
Live — When the work is approved and the job is ready for production, the job is set to Live. Data changes are visible to all and cannot be reverted any more.
Deleted — Pseudo state. Deleted jobs are not stored in the database.
You can also add your own job states. They are stored in the system tables TB_JOB_STATE and TB_JOB_STATE_TRANSITION.
A job may contain one or more topics and each topic has its own job state. The topic's job states are stored in TB_JOB_TOPIC_STATE.
You can use the industry model options to specify whether to perform a job topology check when the job state is changed.
To process jobs, use the Job Manager and Job Explorer in Infrastructure Application Extension or Infrastructure Map Server
Job-enable an industry model
To work with jobs, you must first job-enable the industry model, which locks features so that they can be modified within a job only.
Job-enabling starts certain routines. For example, it adds a JOB_VERSION attribute to each feature class and writes Jobs metadata (TB_JOB* system tables).
WarningDo not edit the Job system tables manually.
Pessimistic Feature Locking
When you job enable an industry model, you lock the features. A feature can be modified in only one job. You can use optimistic or pessimistic job locking. The main difference between the two types of feature locking is the handling of job conflicts. A job conflict occurs if the same feature is modified in different jobs.
Use pessimistic feature locking to detect and solve job conflicts as early as possible.
For example, in Job A you add a transformer on a pole, and in Job B another user B selects the same pole to delete it from the database. With pessimistic feature locking, user B is immediately warned that the feature is locked. User B cannot modify the feature.
To solve the job conflict, user B would contact you, and you can jointly decide how to proceed. For example, you can use the command to extract the respective features from your Job A, so that it can be modified in Job B.
You use to extract a subset of features from the current job to change its state to Live immediately. Then the modified features can be modified again in other jobs.
For more information about , see "Changing the Job State" in the User's Guide.
Optimistic Feature Locking
A feature can be modified in different jobs. Use optimistic feature locking to allow modifications, even if conflicts occur. Job conflicts are not detected immediately, but only when you change the job state. After the first job has been merged forward, and when the second job is being merged forward, the appears.
To work with job-enabled feature classes, you must create a job that contains those feature classes. Use job templates to do this.
A job template contains pre-defined feature classes that can be processed in the jobs that are created from this template. You cannot modify or delete job-enabled feature classes that are not in this job.
You can combine feature classes from different topics into one job template. When you create a job from this template, you can change the state of each topic separately.
Job-enabled feature classes can be edited only if they belong to the current job. A job can be processed only if its state is open.
Job enabled feature classes can be edited only if they belong to the current job. A job can only be processed only if its state is open.
You can define an arbitrary number of job templates with any combination of job enabled feature classes.
You can assign job templates to one or more user groups. For example, to improve security, a user group is allowed to use only a limited set of job templates. In Infrastructure Map Server, members of this user group can work with only the assigned jobs templates and the jobs that were created with those templates.
NoteMembers of the Administrator group can access all job templates, and process all jobs. When you create a user group, all job templates are available to the members of the new group by default.
In the , use the command to assign unassigned job templates to user groups.
NoteExisting jobs from previous versions will not be assigned to a user group, so they can be used by everyone.
Steps in this workflow: