Scopes of Signal in jBPM
💡 Introduction
Signals in jBPM 7 are a core part of event-driven workflow design.
They allow asynchronous communication between process instances, making it possible to start, interrupt, or coordinate processes without direct linking.
However, signals can have different scopes, which define how far the signal travels and who receives it.
Let’s explore the four available scopes in detail:
-
🔹 Process Scope
-
🔹 Default Scope
-
🔹 External Scope
-
🔹 Project Instance Scope
🧩 1️⃣ Process Scope
📘 Definition
Process scope signals are local to a single process instance or its child subprocesses.
They are not visible outside that instance hierarchy.
📋 Use Case
Used for communication inside the same process, like triggering subprocesses or event sub-processes.
🖼️ Process Scope Example
Below is an example of a simple process-scoped signal.
Only this process (or its subprocess) will catch this signal.
⚙️ 2️⃣ Default Scope
📘 Definition
The default scope signal is broadcast to all process instances in the same KIE container (same project deployment).
It’s the most frequently used signal type for inter-process communication.
📋 Use Case
When one process (e.g., Order Process) throws a signal that should trigger another process (Invoice Process) in the same KJAR.
🖼️ Default Scope Example
This diagram shows a signal broadcast from one process to another inside the same container:
.png)
🌍 3️⃣ External Scope
📘 Definition
External scope signals are sent outside the current KIE container — typically through KIE Server REST or JMS endpoints.
They allow cross-container or even cross-server orchestration.
📋 Use Case
When one container (e.g., order-container) needs to trigger a process in another container (e.g., shipping-container).
🖼️ External Scope Example
The below diagram shows how an event sub-process listens to external signals from other systems or servers.
🧱 4️⃣ Project Instance Scope
📘 Definition
The Project Instance scope is used when multiple versions of the same KIE project are deployed, and you want signals to be limited to a specific version of that deployment.
This ensures that processes from version 1.0.0 don’t accidentally trigger listeners from version 1.1.0.
📋 Use Case
Version-specific orchestration inside one container — commonly used in multi-deployment enterprise setups.
🖼️ Project Instance Scope Example
Here’s a representation of signals in a project instance where signal flow occurs only within the same deployed instance:
🧮 5️⃣ Comparison Table
| Scope | Visibility | Communication | Level | Example Use |
|---|---|---|---|---|
| Process | Same process | Local only | Instance | Parent ↔ Subprocess |
| Default | All processes in same KIE container | Broadcast | Container | Order → Invoice |
| External | Other containers / servers | Remote | Global | Cross-container orchestration |
| Project Instance | Processes in same deployment | Version-limited | Project | Versioned project signal |
💻 6️⃣ REST Examples
| Scope | Endpoint | Example |
|---|---|---|
| Process | /server/containers/{id}/cases/instances/{pid}/signal/{signal} | Targeted instance signal |
| Default | /server/containers/{id}/signal/{signal} | Container-level broadcast |
| External | /server/signal/{signal} | Global external signal |
| Project Instance | /server/containers/{deployment}/signal/{signal} | Deployment version-specific signal |
⚠️ 7️⃣ Common Pitfalls
| Issue | Cause | Fix |
|---|---|---|
| ❌ Signal not caught | Wrong scope or name mismatch | Verify signal name and event definition |
| 🔁 Multiple triggers | Duplicate start events | Use unique signal names |
| 🔒 Scope mismatch | Thrown at wrong level | Align BPMN configuration |
| 🚫 REST 404 | Wrong container ID | Check container version |
🧠 8️⃣ Best Practices
✅ Use Process Scope for internal subprocess signaling.
✅ Use Default Scope for container-level communication.
✅ Use Project Instance Scope when managing versioned KJARs.
✅ Use External Scope for inter-server or multi-container orchestration.
✅ Always keep signal names consistent and documented.
👉 Watch “Scopes of Signal in jBPM 7” in Action:
A live demo showing how each signal type behaves with process, default, external, and project instance scopes.
🎬 YouTube: Learn IT with Shikha
👉 Source code: Branches · LearnITWithShikha/SignalsExamples
LearnITWithShikha/SignalsExamples at ExternalScopeExample
🏁 Conclusion
🎯 Understanding the Scopes of Signal in jBPM 7 is essential for designing clean, asynchronous, and event-driven workflows.
💬 “Choose your signal scope wisely — it decides who listens and who stays silent.”
By selecting the right scope:
-
🔹 Process → Isolated and safe
-
🔹 Default → Broad but within project
-
🔹 External → Cross-application integration
-
🔹 Project Instance → Version-safe signaling
you can build robust enterprise workflows that are modular, maintainable, and scalable.
💼 Professional Support Available
If you are facing issues in real projects related to enterprise backend development or workflow automation, I provide paid consulting, production debugging, project support, and focused trainings.
Technologies covered include Java, Spring Boot, PL/SQL, Azure, and workflow automation (jBPM, Camunda BPM, RHPAM).
📧 Contact: ishikhanirankari@gmail.com | info@realtechnologiesindia.com
🌐 Website: IT Trainings | Digital metal podium
Comments
Post a Comment