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.

Feedback

Was this helpful?

Yes No
You indicated this topic was not helpful to you ...
Could you please leave a comment telling us why? Thank you!
Thanks for your feedback.

Post your comment on this topic.

Post Comment