Solved

Process flow application connector not working via an API call

  • 19 January 2021
  • 5 replies
  • 207 views
K.Bakkenes
Rank
Userlevel 3
Badge +9

In the testing phase of SF 2021.1 we tried to change a process flow from using the DB connector to the new Application Connector. However, we don't seem to get this working.

See the process flow below.


When calling the process flow via a POST from Insomnia, we see no results. The process flow stops at the Application Connector (see screenshot below).
 


We expected to see the next process actions in the Indicum Universal DB event log. 

The input of the Application Connector is as follows:


How does this Application Connector work? Are we missing something?

icon

Best answer by Vincent Doppenberg 26 January 2021, 12:13

View original
This topic has been closed for comments

5 replies

V
Rank
Userlevel 6
Badge +4

Hello K.Bakkenes,

I don't see anything wrong with your Application Connector at first glance, but there are various things that could go wrong. Please note that the prc_send_e_mail_v2_appl_connector entry in the DB event log is a process procedure. The DB event log logs database events, such as process procedures, it does not log process actions.

Here are a few tips for debugging process flows:

  1. If you're wondering whether or not a certain action in your process flow is reached, you can add a process procedure to that action and either log a record, raise an error or check the DB event log to determine if that process procedure is called.
  2. If you feel like an error occurs in your process flow then you can check Indicium's logs. All errors produced by process actions will be logged to a log file.
  3. Every process action has the output parameter Status code. The value of this parameter determines the success of the action. A status code of >= 0 means successful (green arrow) and < 0 means unsuccessful (red arrow). The unsuccessful values map to error reasons which can be found in our documentation. You can map the status code output parameter to a variable, read it in the process procedure of that process action and then print it or log it somewhere.
  4. The Windows GUI has a Process Flow Monitor which is available in developer mode. You can simply add a task in your menu to trigger your process flow with and step through it in the process flow monitor to see the result of each action. The Process Flow Monitor will cause the process flow to pause after each action, allowing you step through them one by one.

I hope this helps.

K.Bakkenes
Rank
Userlevel 3
Badge +9

Hello Vincent,

I've applied every suggestion.
1. Added debug code to the existing process procedure. We see that the json_result stays empty.
2. Checked the Indicium logs. No related errors found.
3 and 4. Used a dummy task to start the process flow via the WinGUI (with Indicium (Basic)). The process flow monitor then showed a -100 status code for the application connector.
 

Our process flow now looks like this:
 


Are we using the application connector wrong? Is it even necessary to use an application connector when calling the process flow as an API? Can the application connector be a starting point of a process flow?

V
Rank
Userlevel 6
Badge +4

Hello K.Bakkenes,

The application connector doesn't work on the Windows GUI that's why you're getting the -100 status code there. In this specific case my fourth tip wasn't very useful.

You said that you're not seeing any error messages in Indicium's logs, this would indicate that the application connector ran successfully and returned status code 0, can you confirm that this is the case? If it ran successfully but your ‘json_result’ variable stays null, then the most obvious explanation would be that you did not map the json_result variable to the Result output parameter of the application connector.

The application connector can be the starting point of a process flow, if you start it by means of an API call or a schedule (system flow). It is not necessary to use the application connector when calling the process flow as an API, the database connector would also work. Both process actions are system flow actions, which means that they can be executed autonomously without a user interface.

Please note that in order to start the process flow with a single API call, you will have to remove the dummy task starting point.

K.Bakkenes
Rank
Userlevel 3
Badge +9

Hello Vincent,

after some more debugging I figured out that the JSON result is different. Our process procedure couldn't extract the values of the JSON result. 

DB connector JSON result:

Our code that extracted the JSON result:


Application connector JSON result:


Our new code that extracted the new JSON result:


As you can see the application connector has an extra ‘resultSet’ container. With the new code for extracting the JSON result our system flow works.
However we do see errors in the Indicium Universal log about the read_file_connector. 


Our looping mechanism in the read file connector has an empty file_path as the initial input value. The process procedure behind the process action will loop trough a table with linked documents and fills the file path each time untill the last document is reached and the process step to ‘Stop’ is activated.
Is there a way to prevent this first file_path error?

V
Rank
Userlevel 6
Badge +4

Hello K.Bakkenes,

I'm glad that you have managed to find and resolve your issue.

 

Is there a way to prevent this first file_path error?

Yes, by ensuring that the File connector is only called when there is a file to read. It is a common practice to let a process action loop back onto itself and changing the process variables in the process procedure in order to move the next record, file, etc. The problem is often that the first call fails because the process procedure is necessary to initialize the process variables. This could be solved by initializing the first values of the process variables in the process procedure of the preceeding actions, but in your case, you would have the same logic in three different process procedures then.

For this purpose, we have introduced the Decision process action in version 2021.1 of our platform. I recommend the following setup:

  • Move the logic from the Read file process procedure to the Decision process procedure
  • Have the the Read file process action not loop back onto itself but form a loop together with the Decision process action
  • Use the Decision process action both as the initial process action to enter the loop and as the process action that determines if the loop is broken.

This way you have your logic in one place and the first Read file process action won't fail every time.

I hope this helps.

Terms & ConditionsCookie settings