Question

Mobile app -> event -> workflow does not trigger

K
Rank
Userlevel 4
Badge +10
  • kvbe
  • Hero (Partner)
  • 158 replies

We have following problem with a workflow which does not trigger from a mobile app.

  • We created an event on the ReceiptInfo table (on change of rowstate)
  • If we do a receipt in Aurena / Wadaco in the browser
  • The event triggers 
  • The workflow triggers.

When we use for example the SCANIT app to do a receipt

  • We see the event triggers 
  • But the workflow does not trigger? 

We have set the workflow as async so wondering how we can debug it and how the workflows work together with the mobile apps? 

 

Strange thing is that the custom_event nicely triggers, but not the workflow.

 

@Tharu / @Buddhi Gunasekara / @kamnlk 

11 replies

K
Rank
Userlevel 4
Badge +7

Hi @kvbe,

Few things need to be clarified,

  1. so when you set the workflow as async workflow gets triggered ?
  2. in the scenario 1 (add receipt from browser), is the workflow set as async? or other timing ?
  3. Is the user who is doing the web and mobile app same or atleast have the same permission sets? 

-

You should be able to monitor/view asynchronous workflow runs using the table BPA_ASYNC_SYS_TAB. In here you should be able to see if the job is at least getting submitted 

Im not sure about the SCANIT application itself. but i suspect the ReceiptInfo table update from app comes as a background job. in such a case workflow needs to set as async to be triggered. 

From 23r2 on wards we can capture observation of async job executions using start watch option. 

if you are on a previous version you can use the “ATIR” data in the BPA_ASYNC_SYS_TAB as the input data for troubleshooting (debug) and compare the execution for “IP” status and “DONE”.  (For this you need to convert the ATIR data to valid JSON)

K
Rank
Userlevel 4
Badge +10

@kamnlk Thanks for the tips that helped to assure that the async workflow was actually triggering or not! 

I was not aware about the BPA_ASYNC_SYS_TAB table. 

My main question is now, how can we debug workflows in a better way. 

 

So what I did was the following:

Create a custom event and see if the event triggers in all possible scenario 

  • I used an email action to see if for each time I did my action (aurena / wadaco browser / ifs scanit app) the event was triggered OK
  • Which means I have a working event 

Next step is to create a workflow just with a start and end event 

  • Create an event action to trigger this workflow with a timing async
    • I could see the workflow appearing in the BPA_ASYNC_SYS_TAB table  OK
    • I could see it becomes DONE 

Update the workflow with the logic required

  • Workflow goes into IP stage, without knowing why. 

So my main question is, How can we know what variables are available the moment the workflow executes? How can I know for example , is it PART_NO or PartNo? is "ifsBpaCurrentProjectionName"  actually available yes or no? etc

Can I add an action for example a REST call to an external system to POST the full

execution context to see how the variables arrive at the workflow start event. 

(something like POST ---URL--- ALL EXECUTION VARIABLES in a JSON format)

 

As this is the biggest challenge for ASYNC jobs that you are not 100% what arrives at the workflow. (we are on 23R1 so we cannot upgrade at the moment)

 

So is there a way to get the variable which holds all the execution variables? 

 

 

Rukmal Fernando
Rank
Userlevel 5
Badge +14

@kvbe I tried this recently, so I can share my experience.

First of all, as you pointed out already, only Async from a timing perspective, and Enrichment from Workflow type are supported when initiated from Mobile apps.

Secondly, the parameters you have access to are the parameters you selected from your Custom Event and Event Action.

Thirdly, on the Workflow step, you need to pick your projection for API Name and the correct EntitySet Name corresponding to the Entity you want to do a CUD operation on. The attributes are referred like ${MyAttribute}, and you can interpolate multiple values into a string. Here below is an example based on an internal development app. I hope this gives you a way forward!

Note that on the Custom Event and the Event Action, your attributes will be in the PL\SQL column name format (e.g.: MY_ATTRIBUTE), but from the Workflow, you would refer to them as below. If I remember correctly, the Watch option also lets you inspect variable values that get passed in.

Best regards,

Rukmal

 

 

K
Rank
Userlevel 4
Badge +10

@Rukmal Fernando  thanks for your comment. 

What I am looking for is can I know what variables are available in the execution? 

So how can I see that ${PartNo} is available? or is it ${PART_NO} , what other ifsBpaxxxx variables are available? 

 

So something like, the full list of parameters available when the workflow starts?

Rukmal Fernando
Rank
Userlevel 5
Badge +14

@kvbe my expertise is more in Mobile rather than Workflow, but I’ll share my thoughts anyway.

I think the best approach would be to use Observations where you can see the actual parameters available to the Workflow, but based on @kamnlk’s comments, I believe that’s available in 23R2 onwards.

You can also see the values in BPA_ASYNC_SYS_TAB.ATTR column, and you’d expect to see ${PartNo} as $NEW:PART_NO there.

@kamnlk - I hope you can confirm or offer a better suggestion!

Best regards,

Rukmal 

K
Rank
Userlevel 4
Badge +7

What @Rukmal Fernando said is correct, you should be able to see the values passed into the workflow using the BPA_ASYNC_SYS_TAB.ATTR column.

example:

You should be able to see data similar to the following in that column

!WF_RECEIPTINFOEVENT
$LU=ReceiptInfo
$NEW:INV_PART_NO=
$NEW:RECEIPT_NO=1
$NEW:ROWSTATE=Cancelled

 this should ideally be available to workflow as follows. 

{
 "InvPartNo":null,
 "ReceiptNo":1.0,
 "ROWSTATE":"Cancelled"
}

 

Y
Rank
Badge +1

Hi @Rukmal Fernando  , 

${PartNo} as $NEW:PART_NO 

In the workflow do we have to refer the above column as ${NEW:PART_NO} ? 

I see the entry in the BPA_ASYNC_SYS_TAB.ATTR column. 

But no observations in the BPA. in cloud version 23R2 . 

And this work flow works perfectly in the cloud but not triggered from mobile  work order . 

 

Thank you and best regards, 

Yasara

Rukmal Fernando
Rank
Userlevel 5
Badge +14

@YaheLK I believe you’d refer to the parameter in the Workflow as ${PartNo}. There is also a recording of a simplified scenario in the 24R1 Enablement content under the “Platform – Development & Extensibility” area, so please take a look there too!

Best regards,

Rukmal

Y
Rank
Badge +1

@Rukmal Fernando , 

 

The work flow I wrote work perfect with the custom event when timing is after. 

And as per the details given I change the time to async and then check the  BPA_ASYNC_SYS_TAB and i see there is entry with all wanted fields and sad part is its in IP status. 

Another observation is that all the entries in that table are in the status IP. even the standard ones provided by IFS.  Probably some other thing that need to process these is missing for this environment. 

Customer is in 23R2 and we cannot wait until it go 24R1 which will be end of July or later. 

So trying a different approach for now. 

 

Thank you and best regards, 

Yasara

Rukmal Fernando
Rank
Userlevel 5
Badge +14

@YaheLK the ability to invoke Workflows from Mobile was properly validated and supported in 24R1, but it should work the same way in 23R2 as well, so I’d urge you to followup on that path since you’ve also tried making it async.

@Lahirumala de Mel can you advise on Workflow status being in IP please?

Best regards,

Rukmal

K
Rank
Userlevel 4
Badge +7

@YaheLK  There could be many reasons for the workflow to be in IP. You need to look at the RETRY_COUNT column of the BPA_ASYNC_SYS_TAB  table to get a better idea if its still running or has failed. If the workflow fails for some reason, it only tries to rerun it for up to 3 times. 

Make sure the user mentioned in the USERID of that table have permission to run the APIs inside the workflow.  

what is the ifs version you are using?

There was an issue fixed where async workflows fails when user triggering the initial action has SSO enabled. This fix should be available from ifs releases 23R1SU12, 23R2SU5 onwards.

Reply


Terms & ConditionsCookie settings