I have two tables, Volunteer Requests and Speakers. The Volunteer Request table collects requests from a website through an API to become a speaker. The process model writes to the Request table the status of the Volunteer Request, (Approved or Not Approved), then writes the data to the Speaker table for those Volunteer Requests that are approved.
When I process an approved Volunteer Request, the process throws an error at the XOR decision node.
The error is, "An error occurred while evaluating expression: =pv!volunteerRecord['recordType!PMSO Volunteer Request.fields.volunteerStatusId']=2 (Expression evaluation error : Cannot compare incompatible operands of type Null and type Number (Integer).)"
However, the Write Record smart service Update Request, does it's job perfectly and updates the volunteerStatusId in the pv to 2 for an approved Volunteer Request and writes the data to the database.
The expression in the XOR decision node is:
The field is an integer field and I am comparing to a number. I'm not sure where the null comes in.
Discussion posts and replies are publicly visible
Did you check the data of your pv!volunteerRecord after the write records node? When writing a record, Appian does not return the full record anymore in the updated record data output. I know you mention that you see some data in that PV, but I cannot see at which moment this is.
Thank you for such a quick reply. I see the data at the beginning of the process. I'm not sure how to look at the data at the decision node.
I thought the process carried the process variables throughout the entire process. Does that mean, I need to query the record I just updated?
You don't have to. Depends on whether the DB also changes anything. This behaviour just changed.
Yes, the node wrote the record out to the database.
The Update to the Volunteer Request was successfully updated.
Let's have a quick look at the details here.
You have a PV with some data in your process. You push that data into a write records node to persist the changes. Then you store the updated records value back to your PV. This results in a PV with just the primary key value populated.
If you don't need that record data anymore in your process, you are fine and can stop reading.
If this is a new record you store to DB, you will have to fetch the newly generated primary key value and fetch the full record data either in a separate script task, or in the data outputs of the write records node.
If this is a updated record, use the write records node to push the updates to the DB, but do NOT configure data outputs to store the updated records back to the PV.
Does this make sense for you?
Again, thanks for the quick response.
Would I insert a Query Database smart service to read back the record I just stored?
Then store that back into the pv?
I tried to explain all scenarios in my response above.
A query database node would definitely not be a good choice. Appian is about low-code and not about finding the shortest way to make things complicated again.
I had the same issue. In my process model, I need to use the saved record (in your case volunteer record) in the XOR which was used after the writerecords node. But after writerecords node is completed, the saved record only has the it's primary key value (why it is can be explained by the first screenshot Stefan posted above) populated and all the remaining fields are empty.
What I did was, I created an active class parameter as node input variable to the 'WriteRecords' and initialized with the volunteer record process variable and in the node out this acv variable saved into the volunteer record process variable again. It worked for me.
Not sure why writerecord node was designed only to have the PK value only.
The behaviour of the write records node has changed as Appian added the functionality to als write to related records. The answer to the question of which fields and related records to return cannot be finally answered everybody needs the primary keys.
This has been a very controversial discussion inside the product development team.