SUP operations cant get return / output parameter for HWC ?

[Former Member]

Hi all SUP experts,

I am having a bit of trouble for my BAPI MBO operation that it is unable to retrieve RETURN parameter for HWC.

Can I confirm with you guys that it is not possible ?  this is  not entirely clear to me and I'ved been reading some postings

http://scn.sap.com/thread/2150981

http://scn.sap.com/thread/3311505

which suggest to create another MBO for quering output parameter and some workaround.

then i found this comment, which i havent tried yet as well.

http://scn.sap.com/thread/3187171

"While creating the MBO for order creation, you would have had multiple output tables in your BAPI (For ex, RETURN,OUTPUT etc). You mush have selected these two at least. I assume that RETURN contains the status of the order creation (SUCCESS,FAILED,WARNING) and the OUTPUT contains the order number if the order creation is successful.

In your case, after the BAPI is executed, you have to check the records present in these two MBOs (RETURN, OUTPUT).

In Custom.js file, in customAfterSubmit() method, use getCurrentMessageValueCollection() to get the message value pairs that would have been populated after the RFC execution.

And get the data for the key "RETURN" and check the status.

Based on the status, either you can display the error msg or order number in the alert.

For more info about MessageValueCollection, read Customizing mobile workflow application section in infocenter.sybase.com"

Is this possible using MessageValueCollection to query the RETURN value ?

Below is my approval operation request, and as you can see there is nothing that shows the RETURN parameter. Im a bit stuck on this at the moment ? what have been your strategy to this ? DCN, another MBO that queries the completed request ? (all sounds like an ugly workaround)

20130612T192842.302|4|SCApprovals:1 -- processing value: SCApprovalList_WI_ID_attribKey

20130612T192842.302|4|SCApprovals:1 -- value 'SCApprovalList_WI_ID_attribKey' is [000000135306]

20130612T192842.305|4|SCApprovals:1 -- processing value: status_key

20130612T192842.305|4|SCApprovals:1 -- value 'status_key' is [1]

20130612T192842.305|4|SCApprovals:1 -- processing value: user_key

20130612T192842.305|4|SCApprovals:1 -- value 'user_key' is [MY_MGR_003]

20130612T192842.305|4|SCApprovals:1 -- CallMMSViaMessageChannel->In

20130612T192842.306|4|SCApprovals:1 -- JsonHeader: {"id":"ba3c5c4ce72740018d2c31e298e55f6b","cid":"3#SCApprovals:1","pv":"1","pid":"moca://Simulator5b23f6d1-78ca-4a31-97db-08020dc88c8e__HWC","ppm":"eyJ1c2VybmFtZSI6InN1cEFkbWluIiwicGFzc3dvcmQiOiJoeXBlcnhjaGFuZ2UiLCJTdGF0dXNQSyI6IjAifQ==","method":"replay","pbi":"true","upa":"c3VwQWRtaW46aHlwZXJ4Y2hhbmdl","appId":"HWC","mbo":"SCApproveRejectApproveOperation","app":"SCApprovals:1","pkg":"ShoppingCartApprovals:1.0"}

20130612T192842.306|4|SCApprovals:1 -- JsonContent: {"IV_WORKITEM_ID":"000000135306","ApproveCalled":true,"IV_STATUS":1,"IV_USER":"TNB_MGR_003","_op":"C"}

20130612T192842.555|4|SCApprovals:1 -- ResponseHeader: {"id":"ba3c5c4ce72740018d2c31e298e55f6b","app":"SCApprovals:1","pkg":"shoppingcartapprovals:1.0","pv":"2","method":"replayResult","mbo":"SCApproveRejectApproveOperation","log":"[{\"_op\":\"N\",\"level\":\"INFO\",\"code\":200,\"eisCode\":\"\",\"message\":\"Successful\",\"component\":\"SCApproveReject\",\"entityKey\":\"0\",\"operation\":\"Approve\",\"requestId\":\"ba3c5c4ce72740018d2c31e298e55f6b\",\"timestamp\":\"2013-06-12 11:28:42.332\",\"messageId\":110002,\"_rc\":0}]","cid":"3#SCApprovals:1","sig":"20e53453009c46b6b62cc7b3abb24f52"}

20130612T192842.555|4|SCApprovals:1 -- ResponseContent: {"id":110001}

20130612T192842.555|4|SCApprovals:1 -- CallMMSViaMessageChannel->Out

20130612T192842.555|4|SCApprovals:1 -- ExecuteRequest->Out

20130612T192842.556|4|SCApprovals:1 -- Data(Out): <M><H></H><S>SCApproveRejectDetail</S><A>Approve</A><VS><V k="SCApprovalList_WI_ID_attribKey" t="T">000000135306</V><V k="_old.SCApprovalList.WI_ID" t="T">000000135306</V><V k="status_key" t="N">1</V><V k="user_key" t="T">MY_MGR_003</V><V k="ErrorLogs" t="L" /><V k="SCApprovalList_WI_TYPE_attribKey" t="T">W</V><V k="_old.SCApprovalList.WI_TYPE" t="T">W</V><V k="SCApprovalList_WI_CREATOR_attribKey" t="T">          FLOWITEM  0000001353040000000211000000</V><V k="_old.SCApprovalList.WI_CREATOR" t="T">          FLOWITEM  0000001353040000000211000000</V><V k="SCApprovalList_WI_LANG_attribKey" t="T">E</V><V k="_old.SCApprovalList.WI_LANG" t="T">E</V><V k="SCApprovalList_WI_TEXT_attribKey" t="T">Complete Shopping Cart 6000000067 with Value 12.00 MYR</V><V k="_old.SCApprovalList.WI_TEXT" t="T">Complete Shopping Cart 6000000067 with Value 12.00 MYR</V></VS></M>

20130612T192842.556|4|SCApprovals:1 -- ProcessSyncRequest->Out

[midhun_vp · Accepted solution]

The workaround is given by from Sybase is to create a separate MBO that uses that create RFC/BAPI as the definition/load/read operation. As you've found, create MBO operations don't have output parameters, which is why we need to use the definition/load/read operation. You can then bind the output of your RFC/BAPI to attributes of the MBO. Run an object query on the MBO, passing in the create parameter values, and the instance of the MBO you get back will have its attribute values filled with the output of your RFC/BAPI.

- Midhun VP

[Former Member · Accepted solution]

Thanks Midhun, always good advise from you. Will look into it but not too happy with these kind of workarounds.

[david_brandow · Accepted solution]

As some background, I can provide an explanation for why CUD operations do not provide return/output parameters, although it may not provide much consolation. The essence of it is that SUP is designed around an occasionally-disconnected use case scenario, meaning that when you execute the operation, there is no guarantee that you will be able to execute it right away, it may have to be placed in a queue and executed later, when connectivity can be established. Since the operation may not be executed by the time it returns, there is no meaningful way to return the results. I should note that this is a generic problem, it isn't something unique to SUP.

Where SUP doesn't currently have an optimization is in the online scenario. When you know that you are online, or when you are willing to wait for a response (potentially giving up after a timeout if no response is received), then you should, in principle, be able to get return/output parameters. It is here that SUP has a limitation, which can be avoided using the aforementioned workaround/solution. You will likely find that in practice it isn't that significant.

[Former Member · Accepted solution]

Thanks David for thoughtful background information.