14 The Work Management API
The Work Management API exposes certain functions of the Oracle Communications MetaSolv Solution Work Management subsystem and certain information in the database that the Work Management subsystem uses.
-
Implementation of external applications that use the Work Management API follows the pattern described in "Asynchronous Interaction Pattern".
The Work Management API can be used to provide limited access to Work Management subsystem functions and information from remote and local locations for both field personnel and other users of MetaSolv Solution. Possible examples of applications that can be developed using the Work Management API are:
-
An application that electronically generates tasks for service requests that are received electronically, which eliminates the need to generate tasks for these service requests manually.
-
A Web interface or application that monitors a work queue, reports new tasks in that queue to the user (an individual or work group), and reports completion of specific tasks and gateway events by that user back to the Work Management API. For example, if the credit department must complete a credit check task prior to order completion, the credit department could use an application that notifies them when credit check tasks have been assigned to them. As the assigned tasks are completed, the credit department could use this application to report completion of the tasks.
-
A thin client or Web interface for field personnel that displays their work queue, displays the service request for which the task is performed, displays the relationships and dependencies between tasks, and allows users to report task completion and the reason that tasks were completed late. This type of application could be used in situations where it is difficult or impossible to run the entire MetaSolv Solution application remotely.
The CORBA servername used by the Work Management API is WMSERVER.
WMSession Interfaces
Figure 14-1 shows the relationship of the interfaces within the Work Management API.
WDIManager
Table 14-1 lists the operations available in the WDIManager interface of the WDIWM.IDL file.
Table 14-1 WDIManager Interface Operations in Work Management API
| Operation | Description |
|---|---|
|
startWMSession |
Obtains the object reference of the WMSession |
|
destroyWMSession |
Terminates the WMSession |
|
startTransaction |
commit rollback |
|
destroyTransaction |
Terminates the transaction |
|
startSignal |
eventOccurred eventTerminated eventInProgress eventCompleted eventErrored |
|
destroySignal |
Terminates the signal |
|
startInSignal |
eventInProgress eventCompleted eventErrored |
|
destroyInSignal |
Terminates the InSignal |
Note:
See "Common Architecture" for more information on the WDIManager interface.WMSession Interfaces
Table 14-2 lists the three operations that comprise the WMSession in the WDIWM.IDL file.
Table 14-2 Work Management API WMSession Interface Operations
| Operation | Description |
|---|---|
|
startTaskGenerationSubSession |
Obtains the object reference for the TaskGenerationSubSession |
|
destroyTaskGenerationSubSession |
Triggers destruction of the TaskGenerationSubSession object |
|
startTaskViewingSubSession |
Obtains the object reference for the TaskViewingSubSession |
|
destroyTaskViewingSubSession |
Triggers destruction of the TaskViewingSubSession object |
|
startTaskCompletionSubSession |
Obtains the object reference for the TaskCompletionSubSession |
|
destroyTaskCompletionSubSession |
Triggers destruction of the TaskCompletionSubSession object |
WMSession Interface Operation Descriptions
-
startTaskGenerationSubSession
Obtains the object reference for the TaskGenerationSubSession
-
destroyTaskGenerationSubSession
Triggers destruction of the TaskGenerationSubSession object
-
startTaskViewingSubSession
Obtains the object reference for the TaskViewingSubSession
-
destroyTaskViewingSubSession
Triggers destruction of the TaskViewingSubSession object
-
startTaskCompletionSubSession
Obtains the object reference for the TaskCompletionSubSession
-
destroyTaskCompletionSubSession
Triggers destruction of the TaskCompletionSubSession object
The requestID parameter used by many of the operations in the Work Management API is an arbitrary, user-defined number that provides a means of relating requests and notifications when performing asynchronous operations. The Work Management operations do not make use of this parameter. Instead, they return it unchanged and unevaluated when executing the notification method.
Many of the descriptions of the operations in the Work Management API state that the operation returns a value or values. In such cases, remember that the operation returns that value by invoking the appropriate response operation on the notification object.
TaskGenerationSubSession Interfaces
Table 14-3 lists the operations available in the TaskGenerationSubSession session of the WDIWM.IDL file.
Table 14-3 Work Management API TaskGenerationSubSession Interface Operations
| Operation | WDINotification Operations |
|---|---|
|
generateAndSaveTasks |
generateAndSaveTaskSucceeded generateAndSaveTaskFailed |
|
getAllQueues |
getAllQueuesSucceeded getAllQueuesFailed |
|
getAllProvPlans |
getAllProvPlansSucceeded getAllProvPlansFailed |
|
getPlanID |
getPlanIDSucceeded getPlanIDFailed |
|
getAutoPlanID |
getAutoPlanIDSucceeded getAutoPlanIDFailed |
TaskGenerationSubSession Interface Operation Descriptions
-
generateAndSaveTasks
Given an order (document_number), a provisioning plan ID, and the time zone of the client, this operation generates tasks for that order along with completion dates for each task. A sequence of tasks with their dates are returned along with a sequence that contains the relationship between these tasks and a status. generateAndSaveTasks supports the MetaSolv Solution rules and behaviors functionality when generating tasks.
-
getAllQueues
This operation provides the functionality to return a sequence of all available work queues in the MetaSolv Solution database if the work queues are to be manually assigned.
-
getAllProvPlans
This operation provides the functionality to return a sequence of all available provisioning plans in the MetaSolv Solution database if the provisioning plan is to be assigned manually.
-
getPlanID
This operation provides the functionality to return a specific provisioning plan name specified by the third party developer. This operation returns the ID of the plan using a plan name. This is an alternative method to choosing a default provisioning plan for internet services.
-
getAutoPlanID
This operation provides the functionality to automatically pick a provisioning plan based on predefined third-party criteria. This operation returns the first plan ID which is defined under the organization, jurisdiction, and the service group of the given order (document_number.)
TaskViewingSubSession Interface Operations
Table 14-4 lists the operations available in the TaskViewingSubSession.
Table 14-4 TaskViewingSubSession Interface Operations
| Operation | WDINotification Operations |
|---|---|
|
getUserWorkQueue |
getUserWorkQueueSucceeded getUserWorkQueueFailed |
|
getWorkGroupWorkQueue |
getWorkGroupWorkQueueSucceeded getWorkGroupWorkQueueFailed |
|
getTasks |
getTasksSucceeded getTasksFailed |
|
getPredecessorTasks |
getPredecessorTasksSucceeded getPredecessorTasksFailed |
|
getFollowerTasks |
getFollowerTasksSucceeded getFollowerTasksFailed |
|
getTaskCircuits |
getTaskCircuitsSucceeded getTaskCircuitsFailed |
|
getTaskChecklist |
getTaskChecklistSucceeded getTaskChecklistFailed |
|
getTaskGWEvent |
getTaskGWEventSucceeded getTaskGWEventFailed |
|
updateChecklist |
updateChecklistSucceeded updateChecklistFailed |
|
updateGWEvent |
updateGWEventSucceeded updateGWEventFailed |
|
getServReqTasks |
getServReqTasksFailed getServReqTasksSucceeded |
|
acceptTask |
acceptTaskFailed acceptTaskSucceeded |
|
updateEstCompDate |
updateEstCompDateFailed updateEstCompDateSucceeded |
|
transferTask |
transferTaskFailed transferTaskSucceeded |
|
rejectTask |
rejectTaskFailed rejectTaskSucceeded |
|
searchWorkQueue |
searchWorkQueueFailed searchWorkQueueSucceeded |
|
getTaskDetail |
getTaskDetailFailed getTaskDetailSucceeded |
|
getServReqDetail |
getServReqDetailFailed getServReqDetailSucceeded |
|
getServReqNotes |
getServReqNotesFailed getServReqNotesSucceeded |
|
addServReqNote |
addServReqNoteFailed addServReqNoteSucceeded |
|
getTaskJeopardy |
getTaskJeopardyFailed getTaskJeopardySucceeded |
|
getTaskJeopardyDetail |
getTaskJeopardyDetailFailed getTaskJeopardyDetailSucceeded |
|
addTaskJeopardy |
addTaskJeopardyFailed addTaskJeopardySucceeded |
|
updateTaskJeopardy |
updateTaskJeopardyFailed updateTaskJeopardySucceeded |
|
deleteTaskJeopardy |
deleteTaskJeopardyFailed deleteTaskJeopardySucceeded |
|
getJeopardyCode |
getJeopardyCodeFailed getJeopardyCodeSucceeded |
TaskViewingSubSession Interface Operation Descriptions
-
getUserWorkQueue
This operation provides the functionality to return all work queues owned by the user ID passed in to the operation. This process uses some of the existing functionality and SQL used in the Work Management subsystem to build a list of personal work queues.
-
getWorkGroupWorkQueue
This operation provides the functionality to return all work queues except those owned by the user ID passed in to the operation. This process uses some of the existing functionality and SQL used in the Work Management subsystem to build a list of work queues.
-
getTasks
This operation provides the functionality to return task information for the work queue passed in to the operation. Date/time fields are converted to local time using the local time zone that is passed in. Task information returned includes task_type, task_status, revised_completion_date, queue_status, type_of_sr (type of service request) pon, first_ecckt_id, document_number, and task_number.
-
getPredecessorTasks
This operation provides the functionality to return the task information of predecessor tasks for a given task. Predecessor task information includes task_type, task_status, scheduled_completion_date, actual_release_date, revised_completion_date, estimated_completion_date, work_queue_id, actual_completion_date, task_critical_date_ind (critical task ind), task_status_date, document_number, task_number, first_jeopardy_id (jeopardy ind), and auto_comp_ind (auto completion ind.)
-
getFollowerTasks
This operation provides the functionality to return follower task information for a given task. Follower task information includes task_type, task_status, scheduled_completion_date, actual_release_date, revised_completion_date, estimated_completion_date, work_queue_id, actual_completion_date, task_critical_date_ind (critical task ind), task_status_date, document_number, task_number, first_jeopardy_id (jeopardy ind), and auto_comp_ind (auto completion ind.)
-
getTaskCircuits
This operation provides the functionality to return circuit information as it relates to a given task. Task circuit information includes ecckt (circuit ID), act_comp_date (circuit completion date), jeopardy_ind, ckt_design_id, complete_ind (circuit completion ind) and, notes_ind (circuit notes ind.)
-
getTaskChecklist
This operation provides the functionality to return the checklist items for a given task. Task checklist information includes check_code (checklist identifier code), check_comp_date (checklist completion date), check_seq, check_desc (checklist description), and complete_ind (checklist completion ind.)
-
getTaskGWEvent
This operation provides the functionality to return the gateway events for a given work_queue_id. Task gateway event information includes event_id, event_nm (event name), task_type, task_type_pre (predecessor task to gateway event's task), force_reopen_ind, status_cd, version, signal_ind, in_out_cd, event_detail, document_number, task_number, task_number_pre, and serv_item_id.
-
updateChecklist
This operation updates the MetaSolv Solution database when the user changes the Completion Indicator field. The completion date for the checklist item is set to null if the completion indicator is set to N or it is set to the current date and time if the completion indicator is set to Y.
-
updateGWEvent
This operation provides the functionality to update the Status field in the gateway events tables.
-
getServReqTasks
This operation returns task information for a given document number (service request). This operation is oriented more toward the view of the service request than the getTasks method is. Date and time information is stored in the MetaSolv Solution database in Greenwich Mean Time (GMT). The Work Management API converts dates and times between the time zone identified by the timezone parameter and the GMT equivalent. This allows coordination of tasks that will be performed in different time zones.
-
acceptTask
In the Work Management subsystem, users acknowledge tasks that have been placed in their work queue by accepting them. This operation allows you to acknowledge a task that has been placed in a work queue.
-
updateEstCompDate
This operation updates the estimated completion date for a specified task. Date and time information is stored in the database in Greenwich Mean Time (GMT). The Work Management API converts dates and times between the time zone identified by the timezone parameter and the GMT equivalent. This allows coordination of tasks that will be performed in different time zones.
-
transferTask
This operation transfers the specified task from the work queue identified by the current WorkQueue parameter to work queue identified by the newWorkQueue parameter.
-
rejectTask
This operation rejects a completed predecessor task. You reject a task to return it to the work queue of the person who completed that task so they can rework the task.
When you use the rejectTask method, the Work Management API changes the rejected task's reject status to R (Rejected) and the task's status to Ready. The API also changes the reject status of all completed follower tasks to R and sets their status to Pending.
Note:
You can find a task's reject status in the rejectStatus field in the predFollow structure and the taskRejectStatus field in the taskView structure.You can find a task's status in the taskStatus field in the predFollow structure and the taskStatus field in the taskView structure.
-
searchWorkQueue
This operation takes a string or partial string passed in through the searchKey parameter and tries to match it to existing work queues in the MetaSolv Solution database. The operation returns a sequence of all work queues that match the search criteria. The type of search is determined by the searchType parameter, a value of ”B” requests a ”Begins with” search, and a value of ”C” requests a ”Contains” search.
-
getTaskDetail
This operation returns task detail information for a given document number and task number. Date and time information is stored in the MetaSolv Solution database in Greenwich Mean Time (GMT). The Work Management API converts dates and times between the time zone identified by the timezone parameter and the GMT equivalent. This allows coordination of tasks that will be performed in different time zones.
-
getServReqDetail
This operation returns basic service request information for a given document number. Date/time information is returned using the timezone you specify in the timezone parameter. Service request detail information includes type of service request, service request status, responsible party, purchase order number, order number, desired due date, supplement type, and CCNA.
-
getServReqNotes
This operation returns a sequence of all notes that have been entered for the designated service request.
-
addServReqNote
This operation adds a service request note for the designated service request.
-
getTaskJeopardy
This operation returns a sequence of task jeopardy information for the document number/task number passed in to the method. Jeopardy information is used to identify why a task is or was in jeopardy of being completed late. Date and time information is stored in the MetaSolv Solution database in Greenwich Mean Time (GMT). The Work Management API converts dates and times between the time zone identified by the timezone parameter and the GMT equivalent. This allows coordination of tasks that will be performed in different time zones.
-
getTaskJeopardyDetail
This operation returns task jeopardy information for a single jeopardy ID passed in to the method. Jeopardy information is used to identify why a task is or was in jeopardy of being completed late. Date and time information is stored in the MetaSolv Solution database in Greenwich Mean Time (GMT). The Work Management API converts dates and times between the time zone identified by the timezone parameter and the GMT equivalent. This allows coordination of tasks that will be performed in different time zones.
-
addTaskJeopardy
This operation adds task jeopardy information for the task number you designate. Date and time information is stored in the MetaSolv Solution database in Greenwich Mean Time (GMT). The Work Management API converts dates and times between the time zone identified by the timezone parameter and the GMT equivalent. This allows coordination of tasks that will be performed in different time zones.
-
updateTaskJeopardy
This operation updates task jeopardy information for the task number you designate. Date and time information is stored in the MetaSolv Solution database in Greenwich Mean Time (GMT). The Work Management API converts dates and times between the time zone identified by the timezone parameter and the GMT equivalent. This allows coordination of tasks that will be performed in different time zones.
-
deleteTaskJeopardy
This operation deletes jeopardy information for a given task on a given service request.
-
getJeopardyCode
This operation returns a sequence of all available jeopardy codes in the MetaSolv Solution database.
TaskCompletionSubSession Interface Operations
Table 14-5 lists the operations available in the TaskCompletionSubSession.
Table 14-5 TaskCompletionSubSession Interface Operations
| Operation | WDINotification Operations |
|---|---|
|
getOrganization |
getOrganizationSucceeded getOrganizationFailed |
|
getWhyMissCode |
getWhyMissCodeSucceeded getWhyMissCodeFailed |
|
completeTask |
completeTaskSucceeded completeTaskFailed |
|
completeTaskOnDate |
completeTaskSucceeded completeTaskFailed |
|
reopenTask |
reopenTaskFailed reopenTaskSucceeded |
|
validateEditActCompDate |
validateEditActCompDateFailed validateEditActCompDateSucceeded |
|
searchCompletedTasks |
searchCompletedTasksFailed searchCompletedTasksSucceeded |
TaskCompletionSubSession Interface Operation Descriptions
-
getOrganization
This operation returns a sequence of all available organization IDs for the organization type defined in the MetaSolv Solution Jeopardy Code Organization Type preference.
-
getWhyMissCode
This operation provides the functionality to return a sequence of whymissed codes used when selecting a whymissed code in the task completion process.
-
completeTask
Given a document number and task number, this operation validates the task to ensure it is ready to be completed. If it passes validation, and is on time, the task is completed. If the task is being completed late, a whymissed code is assigned before completing the task.
-
completeTaskOnDate
This operation completes the task represented by the passed document number and task number, and sets the revised completion date to the passed completionDate if the following conditions are true: The task is late, but not beyond its grace period, and the Allow Edit of Task Completion within Grace Period preference is set to Y. Otherwise, the passed completionDate is ignored.
Note:
The completeTaskOnDate operation uses the same return codes as the completeTask operation. -
validateEditActCompDate
This operation validates whether or not a task's actual completion date can be edited.
-
reopenTask
Reopens the completed task that you identify by document number and task number.
WARNING:
Reopening tasks is not recommended for the following reasons:
-
There is no notification, to the owner of a queue, that a task is a reopened task, and no indication in the status column that the status is "Reopened".
-
If the reopened task has any associated gateway events, those gateway events must be reactivated.
-
If the reopened task is a precondition for a gateway event on another task, that gateway event must be reactivated.
-
If there are any completed follower tasks to the one you want to reopen, you must reopen the follower tasks first. If the follower tasks are not in your own work queue, they reappear, when reopened, in their original work queues with a status of Pending. The original queue's owner does not receive notification of reopened tasks in their queue.
-
-
searchCompletedTasks
This operation returns a sequence of completed tasks that meet the passed search criteria. Date and time information is stored in the MetaSolv Solution database in Greenwich Mean Time (GMT). The Work Management API converts dates and times between the time zone identified by the timezone parameter and the GMT equivalent. This allows coordination of tasks performed in different time zones.
Work Management API IDL Files
The following IDL files are included in the Work Management API:
-
WDIWM.IDL
-
WDIWMTYPES.IDL
-
WDIWMTYPES_V2.IDL
Process Flows
This section contains a sample process flow for a solicited message. Use the sample flows as templates for developing your own process flows.
See "Unsolicited Messages" for the process flow that is used when the Work Management API is the client.
Solicited Messages
A solicited message is a message initiated by MetaSolv Solution. The API plays the role of the client, and the third party application plays the role of the server.
Table 14-6 lists the interfaces and operations that the third-party application implements using the IDL files provided with the Work Management API.
Table 14-6 Work Management API Solicited Message Operations
| Interface | For Implementing These Operations |
|---|---|
|
WDIRoot |
connect disconnect |
|
WDIManager |
startTransaction destroyTransaction |
|
WDITransaction |
N/A |
|
WDISignal |
eventOccurred eventTerminated |
|
WDIInSignal |
N/A |
Sample Solicited Message Process Flow
When the Work Management API is the client, the overall process flows as follows:
-
The API client binds to the third-party server to get a WDIRoot object reference.
-
The API client invokes the connect operation of the WDIRoot interface, which yields a WDIManager object reference.
-
The API client invokes the startSignal operation of the WDIManager interface to get a WDISignal object reference.
-
The API client invokes the eventOccurred operation of the WDISignal interface passing a WDIEvent structure to notify the third-party application that an event registered to them has occurred within the database.
-
The API client invokes the destroySignal operation of the WDIManager interface.
-
The API client invokes the disconnect operation of the WDIRoot interface.
-
Once the third-party server completes processing, possibly involving additional unsolicited messages to the MetaSolv Solution Application Server, the third party server binds to the application server and follows the same process described above for the MetaSolv Solution client with the exception that the eventCompleted/Errored operations are invoked passing the original WDIEvent structure.
If the third-party application encounters an error, it throws a WDIExcp as defined by the IDL. The client handles CORBA system exceptions and WDIExcp exceptions.
Unsolicited Messages
An unsolicited message is a message initiated by the third-party application. For an unsolicited message, the Work Management API plays the role of the server and the third-party application plays the role of the server with the exception of callback processing.
See "Solicited Messages" for the process flow used when the Work Management API is the client.
Enhanced Off-net Automation Functionality and the Work Management API
Table 14-7 lists the interfaces and operations that the Work Management API server (DLRSERVER) implements using the IDL files provided with the Work Management API.
Table 14-7 Work Management API Unsolicited Message Operations
| Interface | For Implementing Only These Operations |
|---|---|
|
WDIRoot |
connect disconnect |
|
WDIManager |
startTransaction destroyTransaction |
|
WDITransaction |
commit rollback |
|
WMSession |
getWMSession |
In version M/5 of MetaSolv Solution, a pair of related enhancements were added to the Work Management subsystem that together provide enhanced automation of off-net orders:
-
Provisioning plan templates can define relationships between tasks on PSRs and tasks on child LSRs. At task generation, when the defined conditions exist for the orders, the Work Management subsystem automatically creates the relationships between the tasks.
-
During the CONF or RCONF task, the due date for the DD task and due dates for predecessor or child tasks can be adjusted automatically based on the FOC date received from an external provider of an LSR or ASR child order.
The Work Management API supports the operation of both of these features. When tasks are generated via the Work Management API, and the defined conditions exist for the orders, the Work Management subsystem automatically creates the relationships between the tasks. When you use the Work Management API to complete a CONF task, and the appropriate conditions exist, the Work Management API automatically adjusts the Due Dates for the order and its tasks as appropriate.
Before you can use these automated features of MetaSolv Solution, you must use MetaSolv Solution to set up the relationships between the provisioning plans and to identify for each ICSC whether automatic date adjustment is permitted. See the online Help for more information.
Implementation Concepts
This section describes the concepts that enable you to implement the Work Management API.
Overview of the MetaSolv Solution Work Management Subsystem
To successfully develop applications using the Work Management API, you must first have a thorough understanding of the MetaSolv Solution Work Management subsystem.
The Work Management subsystem provides users with the tools needed to complete these activities:
-
Define a variety of provisioning plans, which are generic templates of tasks needed to fulfill specific types of service requests
-
Define rules under which MetaSolv Solution can dynamically change a provisioning plan at the time it applies the plan to a specific service request
-
Apply a provisioning plan to a specific service request and:
-
Generate and modify the specific set of tasks needed to fulfill a service request
-
Define and modify the dependency relationships between tasks
-
Define and modify the due dates for tasks
-
Electronically schedule and assign tasks to individuals and work groups such as departments and field offices across the organization
-
Track and report on task completion
-
Report why a task was completed late
After each service request is entered, a user generates the tasks for that service request. During task generation, the user can add or remove tasks, change task due dates, adjust the dependency relationships between tasks, and determine the work queue to which each task is assigned.
After any needed adjustments are made to the tasks, and the work queues are selected, the Work Management subsystem dispatches the tasks to the specific work queues.
In the Work Management subsystem, after a given task is completed:
-
The completed task's predecessor tasks and immediate follower tasks can no longer be added to or removed from the service request
-
The dependency relationships between the completed task and its predecessor tasks and immediate follower tasks can no longer be changed
After a worker is assigned to a task, the worker can use the Work Management subsystem to monitor the status of the tasks assigned to them. When a task reaches Ready status, the worker performs the work and changes the status of the task to Completed. The Work Management subsystem then changes the status of any follower tasks that directly depend on the task just completed from Pending to Ready.
Work Management Operational Differences
Table 14-8 lists the similarities and differences between the operation of the Work Management API and the Work Management subsystem.
Table 14-8 Work Management Subsystem and Work Management API Differences
| Key Work Management Function | WM Subsystem | WM API |
|---|---|---|
|
Define provisioning plans |
Yes |
No |
|
Define rules and behaviors by which MetaSolv Solution can dynamically change a provisioning plan |
Yes |
No |
|
Apply previously defined provisioning plans to service requests |
Yes |
Yes |
|
Add tasks to, copy tasks within, or remove tasks from a service request after the provisioning plan has been applied |
Yes |
No |
|
Mark a task Required or Not Required |
Yes |
No |
|
Define the dependency relationships among the tasks on a provisioning plan |
Yes |
No |
|
Accept a task |
Yes |
Yes |
|
Add, remove, or modify the dependency relationships between the tasks assigned to a service request |
Yes |
No |
|
Define the default due dates and duration for tasks |
Yes |
No |
|
Modify the due date for tasks at the time of task generation |
Yes |
No |
|
Change the estimated completion date for a task |
Yes |
Yes |
|
Display task due times that are adjusted for the user's local time |
Yes |
Yes |
|
Assign tasks to the default work queues defined in the selected provisioning plan |
Yes |
Yes |
|
Override the default work queue assignments for one or more tasks at the time of task generation |
Yes |
Yes |
|
Dispatch tasks into work queues |
Yes |
Yes |
|
Track information for one or more of the tasks assigned to a specified service request, including each task's current status, due date, dependency relationships, and the work queue to which it has been assigned |
Yes |
Yes |
|
Track the tasks in a specified work queue |
Yes |
Yes |
|
Transfer tasks from one work queue to another |
Yes |
Yes |
|
Set a task's status to Complete using the current date/time |
Yes |
Yes |
|
Set a task's status to Complete using an earlier date/time |
Yes |
Yes |
|
Auto-complete tasks marked as auto-completable when their follower task is completed |
Yes |
Yes |
|
Auto-complete tasks marked as auto-completable at the time of task generation when the task has no follower task |
Yes |
No |
|
Re-open a completed task |
Yes |
Yes |
|
Reject a task that was completed earlier and return the rejected task to the work queue of the employee or work group that initially completed the task, along with the reason for the rejection |
Yes |
Yes |
|
View task detail information for a given task |
Yes |
Yes |
|
Assign jeopardy codes to tasks or to circuits associated with a task |
Yes |
Yes |
|
Assign notes to an order or to circuits on a task |
Yes |
Yes |
|
Report why a task was completed late |
Yes |
Yes |
|
View the service request detail |
Yes |
Yes |
|
View notes that have been added to the service request |
Yes |
Yes |
Tasks That Cannot be Completed Through the Work Management API
The Work Management API cannot complete any tasks that are in Pending status.
When the tasks from the following list are in Ready status, they cannot be completed through the Work Management API even though they can be completed through the Work Management subsystem:
-
CAD: Carrier Access Billing System (CABS) Acknowledgment Date task
-
CID: CABS Issue Date task
-
DD: Due Date task
Note:
When configured to do so, the MetaSolv Solution System Task server can automatically complete DD tasks. However, the Work Management API does not handle the completion of the DD task. If you attempt to complete a DD task through the Work Management API, the API returns an exception. -
EUAD: End User Billing Acknowledgement Date task
-
EUID: End User Billing Issue Date task
All other MetaSolv Solution-defined tasks in Ready status and all customer-defined tasks in Ready status can be completed through the Work Management API.
Work Management API Support for NET DSGN Task
The Work Management API supports the new NET DSGN (Network Design) task type that was added in M/5.1. API users are able to accept, complete, transfer, and reject NET DSGN tasks when the tasks are included in a provisioning plan just as if they were using the MetaSolv Solution GUI.
Work Management API Support for Date Ready System Tasks
The Work Management API supports the date ready system task feature in the MetaSolv Solution Work Management subsystem.
When API users use the Work Management API to generate and assign a task that the provisioning plan identifies as a date ready system task, the System Task Server does not process that task until its scheduled start date, just as if the task had been generated and assigned using the MetaSolv Solution windows.
Work Management API Support for Backdated and Forward-dated Tasks
The Work Management API supports the backdated and forward-dated task features in the MetaSolv Solution Work Management subsystem.
When an access service request (ASR) or local service request (LSR) is created, the due date (DD) task must be scheduled before the order recipient confirms the order. Backdating and forward-dating means that the tasks after the CONF or RCONF task are rolled forward or backward to accommodate the confirmed dates. See the online Help for more information.