I am trying to create a before workflow that will change the MchCode value entered by the user to something else. At first, I was getting a recursion error by calling the FunctionalObjectHandling projection for the create. That obviously didn’t work.
Does anyone know how to have the workflow just change the variable on the way to the original projection call? I tried just using a workflow with a script component to make the change and I can see the change in the observation but that isn’t actually what is saved.
We are in Cloud 23r1.
Page 1 / 1
Hi Frank.
I have done a quick test on CustomerInfo entity. I hope I understood correctly and that you can extrapolate this example to your use case.
I try to set AssociationNo to ABC but the configuration made saves a predefined value ‘11111’.
When saving…
AssociationNo is automatically set to 11111.
Here is what I did. Create a simple workflow named “bpaReplaceAssociationNo” like this:
Configure a Projection Action on that workflow named “bpaReplaceAssociationNo”:
Then use the form Customer to edit some values. When the record is saved, the workflow kicks in before the actual save and rewrites the value for key AssociationNo to ‘11111’. Then workflow ends and control is given to the actual save (PUT action).
Then after save, the record is refreshed on screen with the proper value.
Thank you much.
Best regards.
Gonzalo.
Hi @Frank H
I tried this out of curiosity and looks like the value change done with the script does not affect for MchCode. But the change is affected for other values (MchName)
I’m thinking this could be due to MCH_CODE is not updatable from entity level. But it doesn’t make sense because my workflow executes on Before the data call. Hope someone from IFS can answer on this.
Here’s my simple workflow.
Projection action
As you also mentioned, changed value can be seen in the observation but not set in the database
Cheers!
Damith
Hi.
As Damith indicates, maybe the MCH_CODE value is changed by the PLSQL business logic of the entity after it has been changed by the workflow.
@dsj Thanks for the help. That is what I tried after my first post as well. I think you may be correct about not being editable at the entity level.
@Gonzalo Can you explain more on your suggestion for the Entity Service API? I’m willing to try anything. Our company is part of a partner group so if this requires making any changes in the build place then I will probably not be able to make those changes.
If a field is not editable at database entity level I don’t think there is a way you can edit it from a Workflow. Not even by Entity Service APIs.
Hi Frank.
I think Lahirumala is correct. Entity Service APIs are meant to make it easy create integrations by allowing direct access to Entity Sets using their own “official” API. But that doesn’t mean that you can bypass business logic.
What I mean with this, and I think it is what Lahirumala indicates, is that eventually, the API endpoint relies on the Entity PLSQL package that handles the business logic. If a specific Entity has some rules on how to set a particular property (example, the PLSQL auto-generates the value) then it doesn’t matter if you provide a value or not for it. It will always rule the business logic. This applies on create and on update. There are business rules for each situation.
So based on this explanation, if the MCH_CODE is set by following some string business rules in the Entity PLSQL package you won’t be able to change that using a workflow and a projection action or event action.
The only way you can go is by doing a modification which alters the business logic written in PLSQL. Most probably you will have to do a partial @overtake on the relevant procedure and locate the section which handles the MCH_CODE value and rewrite it to your needs.
Thank you much.
Best regards Gonzalo.
If a field is not editable at database entity level I don’t think there is a way you can edit it from a Workflow. Not even by Entity Service APIs.
Hi @Lahirumala de Mel
I have few questions regarding this scenario :)
Same problem occurs with workflow timing Before, and on Create. I assume it should be possible to change the value from the workflow since still the projection call has not happened yet?
No errors were thrown during the execution and the observation confirms that the value has changed. Then where does the validation occur?
I even tried to set the workflow trigger as fetching the default value when pressing new button (FunctionalObjectHandling.svc/EquipmentFunctionalSet/IfsApp.FunctionalObjectHandling.EquipmentFunctional_Default()) and still the value set for MchCode is not returning to the client. How would that explain?
Cheers!
Damith
I am still curious like @dsj stated above. Since we do not want to modify anything in our build place, I think we will not be able to automate this. If anyone does find a solution, I would love to hear about it.