Problem with Guard Condition (Fields Disabling)

[Former Member]

Hi All

I have a screen where I am creating a notification... so I enter all my fields and data as below:

If ALL fields are filled out then the call to my RFC will create the notification and pass back a notification number (EX_QMNUM)

I then pass back EX_QMNUM to the input of my READ_S1 RFC. Since we have a custom table attached I thought it was best to retrieve the latest data from the database after point of save.

However if they don't fill in the necessary criteria then I pop up an error (EG. Please fill in customer number). I put a GUARD CONDITION on the call back to the READ_S1 RFC. The guard seems to work as my breakpoint/RFC does not get hit... however it then CLEARS my fields and DISABLES everything. This is what it looks like after the save (with guard condition in place). This means I lose all my data and no save occurs.

What am I doing wrong here? Is this a bug with the guard condition?

Guard Condition (which seems to be working apart from the fact it disables my RGA fields)

I'm not completely sure about IF conditions so let me know if this is wrong?

[former_member202465]

Hi Brad,

I might need more details to point the problem, but I would try this for start:

• For the Form fields to be disabled, it means that no data was returned from its origin Data Service.
• I notice that the Table activates the "save rga" Service on the same event as the Form.

So - could it be that this additional activation of "save rga" causes the flow to continue to "reads1" with no returned data? It might be easy thing to check - just not to "listen" to the same "saverga" event.

Thanks,

Udi

[Former Member]

Hi Ehud

This problem is actually becoming a real pain in that I'm worried I won't be able to continue modeling the application in VC. If you can help me that would be greatly appreciated as I have sunk ALOT of time in to this application and it is now very complex.

I tested the problem further and I can confirm that the guard condition is returning false and IS NOT triggering the READS1 function. I put a external breakpoint in the RFC.

I tested this even further by instead creating a NEW CONNECTOR to ANOTHER CALL of READS1 (after SAVE RGA occurs) and set the guard condition as false. This still wipes the data so this means as soon as the condition is false all data afterwards is wiped out and is not the result of some 'endless loop'. See attached screenshot.

This must be a bug as I can't see any logic as to why this would occur? As I understand it the guard condition is to PREVENT the flow from proceeding and is the only way to control events.

Cheers

Brad

[former_member202465]

Hi Brad,

I'll do my best, let's "start small" and add modeling as we go.

First, I want to be sure I understand the desired flow - please correct me as needed:

1. User enters input in a Form for a new Notification
2. This activates a data service that adds the Notification in the DB. The output is the Notification number.
3. You want to read this new notification now from the DB. You also want to present it in the same input form of step 1?

If all is true, the basic flow is something of this kind:

Is it correct so far?

Thanks,

Udi

[Former Member]

Hi Ehud

Yep that is perfect! I just want to confirm that this flow should work fine when no errors are present and you add a notification successfully.

The problem begins when.... the add_notification function should validate some of the data inputs and if they are incorrect then it should also return an error. You should put a guard condition between 'add_notification' and 'get_notification_by_num' that returns false in these instances.

You can even test this by just adding 'false' between the two if your system is the same as mine! The result you should be that all the data in the 'in1' form you initially entered will be blank AND greyed out (read only).

Cheers

Brad

[former_member202465]

Hi Brad,

Thanks for the input, I have tried this now.

1. In the case the guard evaluates to "false", I experience the fields being blank, but not grayed out. So the user is able to refill the input and submit. This means something else in your model causes the "grayed out" behavior.

2. In general, in case you know the conditions to valid input in the client side, you could model this way:

• Valid input => the data services run. example guard to service: =ISNULL(@customer)==false
• Invalid input => the popup shows. example guard to popup: =ISNULL(in1@customer)==true

3. Is it possible in your case to validate the input before running the first query? This will enable to use the Validation feature as in . If possible it's the best way in terms of user experience, in my opinion.

Thanks,
Udi

[Former Member]

Hi Ehud

It would be nice if I could capture everything on the screen as you mention in 3. however the BAPI can return many different errors and there is no way to predict some of these. These include master data problems and I am passing a whole table of data to be validated.

There is definitely a bug here... I set the guard condition as false and it blanks everything. I would not expect this behaviour when the guard should have stopped the flow.

I have a workaround now however.. your idea helped inspire me. I removed the connector from the output from add_notification and it goes to a popup window every time. If the message back from the RFC is an error I display the 'OK' button which has a refresh action. If there is no error I display a 'Fix Errors' button which does not refresh and instead simply closes the popup.

This workaround is fine.. so I think it is something to do with automatic events in complex models like this but I can't pinpoint the exact cause!

Cheers

Brad

[former_member202465]

Hi Brad,

I see now, the scenario performs more checks on the Bapi. This makes things more complex, as a popup is actually being opened from a UI Action, which the Bapi's result is not.

I also agree that a ticket is due here. If you could do it and include your model it's a great help.

Thanks,

Udi

[former_member202465]

Hi Brad,

As you might not want to open a popup for a correct insert, please see another option with no popup. This application presents the error message on the Form, in case of error:

1. Connect a Data Share from the first service. It gets the Notification Number (or -1 for error in my case).

2. Add a Plain Text control on the input form, with an error text.

3. Set the visibility condition so it is presented in case of errors only.

4. Optional: It is also possible to set the error text dynamically, if relevant.

That's it!

Thanks,

Udi

[Former Member]

Thanks for the plain text error idea.. that is good to know as you can style them right?

I can send you the model if you wish but it is connected to other components and these are all connected to custom RFC's. This is going to be a very complex model when its finished. Is there another way?

[former_member202465]

About the styles - sorry! I forgot to show it:

It's possible to define style for a Plain Text control (and also for Table Row / Table cell):

In this case I choose a trivial thing:

You could define several style with conditions, so the first one to evaluate to "true" at run-time is applied.

The text in the Plain Text control could also be a dynamic expression. So combining these two options you could present different text and color according to case:

Please fix input and resubmit for error, or:

A notification item was added successfully.

About the model:

It's best to simplify the error scenario as much as possible.

About the services: we can't to run them internally, but we get the full picture of the flow.

Thanks,

Udi

[former_member182262]

The idea behind using the Guard condition to determine whether or not  READ_S1 should get executed seems okay. I don't think that has anything to do with the reason why all your fields are getting disabled.

What are the input's to your 'Form' which has all the fields that are getting disabled? (the one with job descriptio, customer PO, etc.). I'm thinking that may be the cardinality/RecordSet of this Form is set '0...1' and that could be the reason why all the fields are getting disabled.

Message was edited by: Chintan Mota Reason: typo