Appian Community and Appian Academy are being upgraded. From July 24–August 3, the Appian Community will be in read-only mode. During this time, the site will be read-only and user registration will be disabled. We apologize for any inconvenience this may cause, but a more secure, stable, and performant Community experience is coming soon!
The new Appian Community launches August 3, followed by Appian Academy on August 7. During the migration, Appian Community Edition, Appian Academy, Documentation, Certifications, Instructor-led Customer Training, Partner Sales Training & Accreditation, and Forum (for Appian Partners and Customers only) will remain available.
Hi everyone,
I encountered an issue regarding saving process variable using a!startProcess -> onSuccess on version 25.4, the fv!processInfo.pv.subCategory was not saved back into local variable ri!checkStatusofChangingCategory. Here is the code:
a!startProcess( processModel: cons!NFL_CONS_PROCESS_CHANGE_CASE_TYPE_CATEGORY, processParameters: { subCategory: ri!subCategory, newCategoryId: local!selectedNewCategory }, onSuccess: { ri!saveInto, a!save( ri!checkStatusofChangingCategory, append( ri!checkStatusofChangingCategory,fv!processInfo.pv.subCategory ) ), a!save( local!currentCategory, local!selectedNewCategory ), a!save(ri!subCategory, null), a!save(local!selectedNewCategory, null),
a!startProcess(
processModel: cons!NFL_CONS_PROCESS_CHANGE_CASE_TYPE_CATEGORY,
processParameters: {
subCategory: ri!subCategory,
newCategoryId: local!selectedNewCategory
},
onSuccess: {
ri!saveInto,
a!save(
ri!checkStatusofChangingCategory,
append(
)
),
local!currentCategory,
local!selectedNewCategory
a!save(ri!subCategory, null),
a!save(local!selectedNewCategory, null),
} )
}
Discussion posts and replies are publicly visible
Despite Appian's claims otherwise, they really kind of broke a!startProcess with this "upgrade". They did provide more granular functionality, like what I would normally want when a component gets upgraded, but they offered no path to make use a very commonly used feature of the old one, which was that it acted synchronous along activity chaining and then returned any concurrent process variable values when chaining broke.
There is no way to accomplish this in the newer version for an existing process (as-is) when it doesn't end quickly, as the "synchronous" onComplete save only executes upon actual completion of the process. Their "official" guidance is to break up single processes into layered synchronous/asynchronous levels where the top layer can complete (thus returning synchronous data to your interface) and any subsequent functionality is launched in an async subprocess/startprocess, though this adds undue cumbersomeness IMHO.
To slightly more directly answer your question: your code would need to include "isSynchronous" set to TRUE, because if it's not, it won't return process data at all (annoyingly, since some things, like process ID, could / should be available regardless of synchronicity), and the called process needs to complete. Technically if it doesn't complete, you could capture any current data using the "onIncomplete" save, but this only executes after 30 seconds, regardless of chaining (annoyingly). This is where they should have added some functionality in parity with the old version that could check for data to return upon broken chaining (or perhaps a third synchronicity mode).
But for now we're stuck either compromising, or using the deprecated version (which will work for at least the next 10 years, going by the continued working state of older deprecated components that still stick around).