Is there a way to disable nodes in a process model for testing purposes? At the moment I just disconnect the nodes from the process model, but Appian doesn't seem to like that. I would like to be able to do some equivalent of commenting them out, if there's anything like that.
Discussion posts and replies are publicly visible
Can you go a little bit more into your use case? If it's a node you need to have permanently in place but will usually need to bypass for testing purposes, the standard method is to have an XOR gateway prior to the node that checks the value of either a PV or a constant, to see whether it's in "testing mode" let's say, and executes accordingly.
Hmmm... that seems a little inefficient and heavy on setup for what I had in mind.
This would be while building a process model. For example. I have 10 nodes and know that the first 9 nodes work fine, but am still getting the 10th node to work, is there no way to just ignore the first 9 nodes? If they are forms, for example, it could be a hassle filling out each one individually to see if that 10th node does what it's supposed to do. Or maybe one of the nodes isn't working properly and I want to isolate it to figure out where exactly in the process model that's happening without rewiring everything.
In normal coding, you can just comment out all the parts you don't want to deal with. Is there no equivalent in an appian process model?
Marco said:In normal coding, you can just comment out all the parts you don't want to deal with.
Not really in a process model. My own personal technique for dealing with such a thing in a dev environment is to get a single instance to that node, then edit the instance and restart the node as needed until it's working, then copy that change back over to the model. that way you don't have to, for instance, fill out the forms for 10 user input tasks before a final node that does processing, you just get that far once and then try that node as many times as needed.
Not ideal, but I guess it is what it is. Thanks!
Whilst I have in the past wanted to do the same, it's since occurred to me that (in the example you've given) that the 10th node is actually dependent upon the previous 9 (if in a sequence) and therefore you want to execute the others leading up to it. You could always, as suggested, start an instance, edit the specific node, save and then re-start the instance just from that node until you get the outcome you want, and then retro-fit your changes to the model. Of course, it's best practice to encapsulate functionality wherever you can...so if the node you're talking about is, say, a Script Task then move the code to an Expression Rule where you can test ad nauseum with no overheads.
What I'll usually do is implement a dynamicLink on the forms which automatically populates testing data, then have the field only shown for when isusersystemadministrator(loggedInUser())=true. This way when I need to run through the initial forms quick to get to the nth form, I can open the process, click the link to populate all data, submit, click through the other forms quick with something similar, without having to type in multiple fields to get to later forms - as noted here, almost always down stream processing is affected by up stream processing..
Mike Schmitt said:Not really in a process model. My own personal technique for dealing with such a thing in a dev environment is to get a single instance to that node, then edit the instance and restart the node as needed until it's working,
i do absolutly the same there. As of now, its the most practical approach so far besides testing your rules, interfaces, integrations or what ever in advance, if this is possible