The technical definitions are available as WSDL both for the main definition and test endpoint .
The following documentation, which details every action available, has been generated from the WSDL above.
Port type _-BTI_-TE_TASK_WS
3.2.1 Create a business task
Allows a new business task to be created in ActiveControl with the details specified.
3.2.2 Change a business task
Allows an existing business task to be changed in ActiveControl with the details specified.
3.2.3 Read a business task
Allows an existing business task in ActiveControl to be read to obtain the details.
3.2.4 Start the analysis for a business task
Starts the ActiveControl analysis process for a specific business task.
The status and results of the analysis can be queried later via the “Read the results of an analysis run“ web service using the analysis ID returned so it can be determined if it safe to approve.
3.2.5 Read the results of an analysis run
Reads the results of an analysis run started via the “Start the analysis for a business task” web service. This will return all analysis issues reported for the analysed business task so it can be determined if it safe to approve.
3.2.6 Approve a business task
Perform the approval of a business task. Prior to approval the task should be analysed to determine whether it is safe to approve. Approval will move the task and its associated transports to the next location / process control point in ActiveControl.
3.2.7 Enter the test results for a business task
Allows test results to be entered against a business task. ActiveControl uses a test series to log the test results. Closing the test series will approve the testing and move the task and its associated transports to the next location / process control point in ActiveControl. If the test series is not closed (e.g. due to an unsuccessful test result) the test result are saved but the task and transports will not be approved and will remain open for further testing.
3.2.8 Mapping internal values
All ActiveControl web services and API’s expect the AC internal field values to be supplied for them to function correctly. These internal ID’s can be found in the following configuration and transactional tables:
WS field | Table | Field | Description |
---|---|---|---|
Groupid | /BTI/TE_GROUPS | GROUPID | Task Group ID (Use CLASS = TASK) |
Typeid | /BTI/TE_TYPE | ID | Task Type ID (Use CLASS = TASK) |
Projectid | /BTI/TE_PROJ | ID | Project ID |
Statdepl | /BTI/TE_TASKSTAT | STATID | Deployment Status (Use STATTYPE = DS) |
Statplan | /BTI/TE_TASKSTAT | STATID | Planning Status Use STATTYPE = PS) |
XTarget, Targetid | /BTI/TE_TARG | TARGET | Target ID |
Path | /BTI/TE_PATH | PATH | Path ID |
XAnalysisId, YAnalysisid | /BTI/TE_ANLTYPE | ANLTYPID | Analysis Type ID |
Targetroleid | /BTI/TE_TARGROLE | ID | Target Role ID |
Id, Taskid | /BTI/TE_TASK | ID | Task ID |
XAnltypeid | /BTI/TE_ANLRUN | ANALYSISRUNID | Analysis Run ID |
Reason | /BTI/TE_ANREASON | REASON | Reason ID |
Other mapping and web service fields:
WS Field | Description |
---|---|
XLocation | Location (Possible values: I – Inbox, Q – Import Queue, T – Test Queue, O – Outbox) |
Priority | Priority (Possible values: 1 – Low, 2 – Normal, 3 – High, 4 – Urgent) |
Locked | Locked (Flag values: X and SPACE) |
XRescode | Test Result (Possible values: 0 – Testing Successful, 1 – Problem Found, 2 – Information, 3 – Waiting, 4 – Bypass Testing) |
XClose | Close and Approve testing (Flag values: X and SPACE) |
XDescription | Task long description |
XTask, YTask | Structure for the main task field details |
Caption | Task short description / subject |
Reference | Task unique reference number (e.g. ticket, defect, change request number) |
Testerid | SAP user id of the main task tester |
Statdeplman | Flag to indicate that the task deployment status is manually set rather than allowing ActiveControl to set it (Flag values: X and SPACE) |
Statplanman | Flag to indicate that the task planning status is manually set rather than allowing ActiveControl to set it (Flag values: X and SPACE) |
Systemid | SAP system ID |
XtCustfields, YtCustfields | Task custom field values structure formatted as a list of: • Id – Custom field ID • Value – Custom field value |
XtTesters, YtTesters | Task testers structure to list the testers for the task |
XUpdateCustfields | Flag to indicate whether the task Custom Fields are to be updated (Flag values: X and SPACE) |
XUpdateDesc | Flag to indicate whether the task Description are to be updated (Flag values: X and SPACE) |
XUpdateTesters | Flag to indicate whether the task Testers are to be updated (Flag values: X and SPACE) |
XUpddateTask | Flag to indicate whether the task main fields (in XTask) are to be updated (Flag values: X and SPACE) |
YProblems | Flag to indicate whether any analysis issues were found (Flag values: X and SPACE) |
YRunning | Flag to indicate whether any analysis is still running or not (Flag values: X and SPACE) |
XComment | Test to enter a free text comment during test results entry |
XtRequest – Trkorr | A list of SAP transports to be analysed / approved |
YReturn | WS call return structure to pass back messages and errors |
Msgtyp | Type of message returned from the WS call (Possible values: E – Error, W – Warning, I – Information, S/Blank – Success) |
Msgid | ID of the message returned from the WS call |
Msgnum | Number of the message returned from the WS call |
Message | Message text returned from the WS call |
Msgv1 – 4 | Further message texts returned from the WS call |
3.2.9 Other communication techniques
Although the use of web services is the standard communication technique using ActiveControl, as the product resides in the SAP Netweaver stack, other SAP standard communication techniques are available for integration if preferred.
3.2.9.1 tRFC Communication
All AC APIs exist as remote enabled function modules within the ABAP environment and can therefore be called using the standard tRFC calls through an appropriate RFC destination. If the external system integrating with AC is either another SAP system or able to call remote functions directly then this method of communication can be used.
For inbound scenarios, the standard API’s can be called directly. For outbound scenarios, new send methods would need to be developed to enable direct calling of the external system.
3.2.9.2 IDoc Communication
As with TRFC integration above, as the AC API’s are standard function modules, IDoc wrappers can be created to call them and standard IDoc processing configured to control the integration.
For inbound scenarios, the appropriate IDoc wrappers would need to be generated and any IDoc sub-system configuration completed. Once again, for outbound scenarios, new send methods would need to be developed for IDoc communication to be enabled.
Post your comment on this topic.