cancel
Showing results for 
Search instead for 
Did you mean: 

Fiori; Http Status 307 or Invalid key predicate when approving workflow item

Former Member
0 Kudos

When approving a workflow item in the general Fiori Approval App, the the following message appears;

- Http Status 307 when using iPhone/iPad simulator

- Invalid key predicate when using Chrome browser in Windows 7.

Any idea what could cause this problem?

Frank

Accepted Solutions (0)

Answers (3)

Answers (3)

Former Member
0 Kudos

Dear Paul, Masayuki,

The issue is solved now! We again debugged and found that structure /IWWRK/S_TGW_DECISION_OPTION was incomplete (field Nature was missing). This was caused by the fact that we reimplemented note 1799722. Even while double checking the related note 1805831 we probably overlooked the structure mentioned above.

The structure was updated now and the general approval App is finally working as expected.

Many thanks to you all!

Frank

masa_139
Product and Topic Expert
Product and Topic Expert
0 Kudos

Have you applied all notes mentioned in the install guide?

masa_139
Product and Topic Expert
Product and Topic Expert
0 Kudos

I think you have not implemented the /IWWRK/ES_WF_WI_BEFORE_UPD_IB BADI.

Former Member
0 Kudos

Masayuki,

Thanks for your advice. We have picked up this issue again and debugged. Our error appears before the BADI you mentioned is called, therefore we have investigated further.

The problem is that the URL the App is sending to the gateway system looks as follows; /sap/opu/odata/IWPGW/TASKPROCESSING;mo/TaskCollection(SAP__Origin='ERP_600_PGW',InstanceID='000000385112').

ERP_600_PGW is the system alias for the workflow and Instance ID the workflow item.

However in the data-model of the OData /IWPGW/TASKPROCESSING service there is no key for the SAP__Origin.

Is this missing customising or truly a bug?

Frank

paul_grill2
Explorer
0 Kudos

Frank,

This sounds like missing customizing. Check whether you have the decision keys maintained correctly.

"Maintain Task Names and Decision Options": /IWWRK/SAPLFG_WF_TAB

Add your workflow template and specify the Step Id. Then, switch to "Decision Keys" and maintain decision keys for a positive and negative outcome. I would recommend using "1" and "2". These are passed into your BADI when the end user approves/rejects a workflow item.

Remember that both BADI implementation as well as the aforementioned customizing need to be done on the Backend, not the Gateway instance.

Hope I could help!

Paul

Former Member
0 Kudos

Paul,

Thanks for your feedback.

Maintain Task Names and Decision Options are defined for this workflow template WS77300061. Since step 4 in this template is related to task TS77307918 which is a user decision there should be no need to define the decision keys. Nevertheless I tested both with and without the decion keys, but the result in the general fiori approval app remains the same; Invalid key predicate.

We have an embedded implementation, so back-end and gateway are the same for us.

I must be missing something else, but the question is still; what?

Frank

paul_grill2
Explorer
0 Kudos

Frank,

you will have to maintain the decision keys. It is correct that a task of type "User Decision" already carries the decisions itself in it; however, the BPM gateway component has no way of knowing which of these decisions resemble "Approve" or "Reject". This is why you need to maintain the decision keys. It is very important to fill the last column "Nature" with POSITIVE or NEGATIVE appropriately.

When the Fiori App submits a user's decision, it will first retrieve all possible decisions from the server. The URL for this is as follows:
/sap/opu/odata/IWPGW/TASKPROCESSING;mo/DecisionOptions?SAP__Origin='<system id>'&InstanceID='<task instance id>'

You should be able to verify that this calling this URL returns two entries, just like in the screenshot below:

To the best of my knowledge, there is not really anything else that could cause the invalid key predicate error.

--Paul

Former Member
0 Kudos

Paul,

I have customised the decision keys and tested with the URL provided by you. The result is;

Apparantly I am missing the Nature, allthough I have customised this as such (last field in drop down box)

I remembered and checked some notes in this area but we seem to have implemented them all.

Your help so far is really appreciated! Any further thoughts why the POSITIVE and NEGATIVE values are not retrieved?

Frank

paul_grill2
Explorer
0 Kudos

Hi Frank,

Depending on what version Gateway version you are running, the "Nature" feature came either pre-installed or was deployed through SAP Note 1805831. May I suggest the following two steps:

  1. Use transaction SE11 to view contents of database table /IWWRK/C_WFDEC , and view /IWWRK/V_WFDEC . Both should have a NATURE column. Also check whether values were saved correctly.
  2. If that doesn't show any inconsistencies, set an external breakpoint in class /IWWRK/CL_WF_STEP_CONFIG, method GET_DECISION_KEYS_INFO . This method retrieves the decision options at runtime, so you should be able to see where Nature goes missing.

--Paul

Former Member
0 Kudos

Hi Paul,

We checked database table /IWWRK/C_WFDEC , and view /IWWRK/V_WFDEC and they are OK as we expected.

Also we have set an external breakpoint in class /IWWRK/CL_WF_STEP_CONFIG, method GET_DECISION_KEYS_INFO, but this point was not reached during execution.

Next we have made a trace and below are the results;

Trace

Details of Trace Error

It seems to be that the generic approval Fiori App provides an incorrect URL without multi origin.

To double check we have tested the Error url in the gateway client

/s             /sap/opu/odata/IWPGW/TASKPROCESSING; o=ERP_600_PGW//TaskCollection(SAP__Origin='ERP_600_PGW',InstanceID='000000385118') > ERROR Invalid Key Predicate

/sap/opu/odata/IWPGW/TASKPROCESSING;mo//TaskCollection(SAP__Origin='ERP_600_PGW',InstanceID='000000385118') > NO ERROR

Why does the generic approval Fiori App sometimes provides an URL with multi origin and why sometimes without multi origin?

Frank

paul_grill2
Explorer
0 Kudos

Hi Frank,

the differences in URL are actually not relevant to the invalid key predicate error. ;mo will direct the Gateway server to run the data-providing process on all configured ERP targets while ;o= will limit execution to a single ERP target system. The value of SAP__Origin will then be used for further processing to ensure that the workflow is completed on the correct system.

When a Fiori App posts a user decision to the system, it first queries the /DecisionOptions entity (see above). It then uses the information from the /DecisionOptions entity to compile an URL to which the user's decision will be submitted. If /DecisionOptions did not return any data, the submit URL will be invalid and yield a invalid key predicate error. As a consequence, you definitely need to hunt down this issue. I strongly recommend giving debugging /DecisionOptions another shot. Try setting an external breakpoint a little further up the chain, for example in method wf_tgw_task_dec_op_act. From there, see whether the code ever comes to calling get_decision_keys_info.  I've attached a call stack for comparison. This can be an indicator for missing notes.

Sorry that you are having such a hard time getting this to work.

Good Luck

Paul