2. Using the update method of Duet Enterprise business object integration
For using WF you need to create a SAP WF in the SAP backend system and follow the steps for integration of WF using Duet Enterprise (SDN guide 1 and guide 2).
For the second approach you can include the Release code and other necessary fields in the business object definiton and use them as input fields for the update operation, the PO number can be picked from the SCL key (like you do in Read operation).
Thanks for your valuable suggestion. But as per the duet enterprise developer guide point number 7.2.1,There is a dependency in SharePoint Designer between the Read response structure and the Create request structure and the Update request structure.
But in my scenario, the Update request structure is entirely different from Read Response structure.
The Update Request structure (BAPI_PO_RELEASE) is having purchaseorder and po_rel_code parameters as inputs. But my Read Response structure is having lot more other fields also.
As you discovered already SharePoint Designer ensures that certain dependencies are met between each of the operations. Example: The Updater view must be equal to, or a subset of, the SpecificFinder view.
In your case you could try creating a wrapper RFC for the update operation. The wrapper should have a signature that satisfies the dependencies for an update operation. Inside the wrapper you can then trigger the actual BAPI_PO_RELEASE call.
As you told that the Updater view must be equal to, or a subset of, the SpecificFinder view. The update standard BAPI BAPI_PO_RELEASE is having the field PO_REL_CODE which does not exist in my Read Operation BAPI. How to go about?
My approach:
Since my only concern is to update the release flag only, can I create normal webservice using SOAMANAGER in backend and update the release status to released using sharepoint?
I mean without using duet, can I make use of this BAPI(BAPI_PO_RELEASE) with backend webservice into sharepoint?
I would suggest not to create yet another web service for UPDATE.
Is the PO_REL_CODE field something that needs to be filled in SharePoint or can it be determined programmatically (e.g. set a fixed value)? If so, then create a operation for UPDATE that complies with the prerequisites (e.g. input should be same or similar to output of READ) and return should basically only have a fault message container. When firing the update from SP you should set the key and could ignore all the other fields. With the help of the key field and the constant PO_REL_CODE you can now trigger the RFC BAPI_PO_RELEASE.
If you need to enter the PO_REL_CODE in SP, then you should extend the attribute structure and add this it as an optional attribute (e.g. add it to the output of the READ operation). For READ and QUERY you can basically keep it empty. For the UPDATE operation now you can use it to pass a value (together with the key) to finally fire the RFC.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.