Your user interface contains three independent sections, each displaying data from different database tables. These tables have no foreign key relationships or any other relational links. The requirement is to allow users to update the data in all three sections and save the changes back to the database using Write to Records.
Question 1: How would you design the process model to handle writing data from all three unrelated sections back to their respective tables?
Question 2: Based on your initial design, restructure the process model to demonstrate:
- How an End shape would be incorporated
- How a Terminate shape would be incorporated
Explain the purpose and placement of each within the redesigned flow.
Answer
Question 1: Designing for Multiple Unrelated Sections
When your UI contains three independent sections (A, B, and C) that map to three different database tables with no relational links, the most efficient approach is Parallel Writing.
The Design:
- Start Form: Use a single interface with three distinct rule inputs (e.g., ri!dataA, ri!dataB, ri!dataC).
- Parallel Flow: After the Start Node or User Input Task, use an AND Gateway (Parallel Gateway).
- Independent Nodes: Branch the flow into three separate paths, each containing a Write Records or Write to Data Store Entity smart service.
- Convergence: Use a second AND Gateway/ Script Task to collect the paths before the process concludes.
Why this works: It allows Appian to initiate these writes independently, ensuring that data is persisted to all three tables without needing complex nested CDTs or artificial relationships.
Question 2: Error Handling with End and Terminate Shapes
A basic flow works when everything goes right. But what happens if Section B fails to write while A and C succeed? To make your process "production-ready," you must incorporate specific termination logic.
1. The Regular "End" Shape
- Purpose: Represents the natural completion of a specific path.
- Placement: Place an End Event at the very end of your successful flow (after the converging AND gateway).
- Behavior: When a token reaches a standard End Event, only that specific path ends. If other paths are still active (e.g., if one write is still processing), the process instance continues until all tokens are gone.
2. The "Terminate" Shape
- Purpose: To immediately kill the entire process instance, regardless of other active paths.
- Placement: Connect this to the Exception Flow of your Write nodes. If any of your three writes (A, B, or C) encounter an error, the flow should route directly to a Terminate Event.
- Behavior: As soon as a single token hits a Terminate Event, the entire process instance stops immediately. This is critical for data integrity—if one write fails, you may want to stop the process to prevent the user from thinking the entire transaction was successful.