New Structure

next.config.js

@@ -3,6 +3,7 @@ const withNextra = require('nextra')({
   themeConfig: './theme.config.tsx',
   defaultShowCopyCode: true,
   staticImage: true,
+  showHiddenPages: true,
 });
 
 module.exports = withNextra({

pages/_meta.json

@@ -5,7 +5,7 @@
     "href": "https://www.proceed-labs.org/"
   },
   "about": { "title": "About", "type": "page" },
-  "ms-api": { "title": "MS Api", "type": "page", "href": "/msapi.html" },
+  "ms-api": { "title": "MS API", "type": "page", "href": "/msapi.html" },
   "more": {
     "title": "More",
     "type": "menu",
@@ -20,22 +20,13 @@
       }
     }
   },
+
   "index": "Introduction",
   "quick-start": "Quick Start Tutorial",
-  "downloads": "Downloads",
   "user-guide": "User Guide",
-  "features": { "type": "separator", "title": "Features" },
-  "deployment": "Deployment and Execution",
-  "capability-description": "Capability Description",
-  "versioning": "Versioning",
-  "collaborative-editing": "Collaborative Editing",
-  "monitoring": "Process Monitoring",
-  "bpmn": "BPMN Adaptions",
-  "offline-execution": { "display": "hidden" },
-  "user-mgmt": { "display": "hidden" },
-  "general": { "type": "separator", "title": "General" },
-  "vision": "Vision",
-  "project": "Project Information",
-  "glossary": "Glossary",
-  "showcase": { "display": "hidden" }
+  "developer": "Developer Information",
+
+  "features": { "type": "separator", "title": "Advanced Features", "display": "hidden" },
+  "adv-process-deployment": { "title": "Process Deployment Methods", "display": "hidden" },
+  "adv-capability-description": { "title": "Capability Descriptions", "display": "hidden" }
 }

pages/deployment.mdx → pages/adv-process-deployment.mdx

@@ -28,3 +28,19 @@ location or workload. This means one process literally _jumps_ from machine to
 machine, and thereby can even travel above network boundaries, if it is
 transported with a portable device. This is done until every process instance
 reaches its ends.
+
+## Offline Execution
+
+Distributed Processes Engines don't need any active connections to other engines, systems or coordinators. The process execution can happen completely independently.
+
+If a process needs the capabilities of another system or device for fulfulling the next process steps (which is the usual case), the engine waits until such system is available.
+
+If the process engine is working to its capacity, it rejects new incoming processes or execution requests
+
+Open questions:
+
+- Should there be a configuration option for a wait maximum?
+- Do waiting processes have influence on system performance?
+- How to prevent infinite process execution? Do we need to prevent that?
+- How to design the software components for waiting/listing?
+- Esp. for IoT devices: how to prevent new processes or execution requests? Maybe include a waiting queue?

pages/developer.mdx

@@ -0,0 +1,4 @@
+# Developer Information
+
+The following sites contain information for developers how to use PROCEED externally.
+For example, here we document the APIs or additions to the BPMN XML file.

pages/developer/_meta.json

@@ -0,0 +1,3 @@
+{
+  "bpmn": "BPMN Serialization"
+}

pages/bpmn/_meta.json → pages/developer/bpmn/_meta.json

@@ -2,13 +2,12 @@
   "bpmn-supported": "Supported Elements",
   "bpmn-general-serialization": "General Serialization",
   "bpmn-data-types": "Process Variables and Types",
-  "bpmn-script-task": "Script Task",
+  "bpmn-script-task": "Script Task & API",
   "bpmn-user-tasks": "User Tasks",
   "bpmn-subprocesses": "Subprocesses",
   "bpmn-gateways": "Gateways",
   "bpmn-error-escalation": "Error & Escalation Events",
   "bpmn-timer": "Timer Events",
   "bpmn-constraints": "Process and Task Constraints",
-  "bpmn-versioning": { "display": "hidden" },
   "bpmn-capabilities": { "display": "hidden" }
 }

pages/bpmn/bpmn-error-escalation.mdx → pages/developer/bpmn/bpmn-error-escalation.mdx

@@ -6,7 +6,7 @@ Catching is only possible with a boundary event.
 
 The following shows a BPMN diagram with a Script Task having two catching, interrupting error events and two catching escalation events.
 
-![BPMN Process](/docs/images/bpmn/BPMN_Error_Escalation_Boundary_Events.png?width=350px)
+![BPMN Process](/images/bpmn/BPMN_Error_Escalation_Boundary_Events.png?width=350px)
 
 If you create this diagram in PROCEED's Management System, the following elements/attributes are automatically added for execution:
 
@@ -53,7 +53,7 @@ If you create this diagram in PROCEED's Management System, the following element
 
 ## Subprocesses and Throwing/Catching Error and Escalation Events
 
-![BPMN Process](/docs/images/bpmn/BPMN_Subprocess_error_and_escalation.png?width=550px)
+![BPMN Process](/images/bpmn/BPMN_Subprocess_error_and_escalation.png?width=550px)
 
 For throwing escalation and error events inside a subprocess, nearly the same rules apply as for catching boundary events:
 

pages/bpmn/bpmn-gateways.mdx → pages/developer/bpmn/bpmn-gateways.mdx

@@ -1,6 +1,6 @@
 ## AND Gateway
 
-![BPMN Process](/docs/images/bpmn/BPMN_AND_GW.png?width=400)
+![BPMN Process](/images/bpmn/BPMN_AND_GW.png?width=400)
 
 The AND split enables multiple parallel process flows that run concurrently by creating a new (sub-)token for every outgoing sequence flow.
 
@@ -19,7 +19,7 @@ It goes on if all tokens have arrived.
 
 ## XOR and OR Splitting Gateways
 
-![BPMN Process](/docs/images/bpmn/BPMN_In-Ex-clusive_Split.png?width=600)
+![BPMN Process](/images/bpmn/BPMN_In-Ex-clusive_Split.png?width=600)
 
 The exclusive (XOR) and inclusive (OR) gateways for splitting a process flow are supported.
 
@@ -55,7 +55,7 @@ An outgoing sequence flow is only allowed to have _no_ condition, if the `defaul
 
 ## XOR Joining Gateways
 
-![BPMN Process](/docs/images/bpmn/BPMN_XOR_Join.png?width=200)
+![BPMN Process](/images/bpmn/BPMN_XOR_Join.png?width=200)
 
 In the case of the XOR join, the gateway waits until one token arrives at an incoming sequence flow.
 Then it fowards the token to the outgoing sequence flow.

pages/bpmn/bpmn-script-task.mdx → pages/developer/bpmn/bpmn-script-task.mdx

@@ -33,7 +33,7 @@ triggered because of an unusual high amount of ordered products, the customer
 will be informed of a late shipment. If there occurs an error while processing,
 the customer is informed that the order got canceled.
 
-![BPMN Order Process](/docs/images/bpmn/BPMN_Boundary_Process.png)
+![BPMN Order Process](/images/bpmn/BPMN_Boundary_Process.png)
 
 #### Example Script Code
 
@@ -327,4 +327,4 @@ log.info('Photo taken');
 return { photo: image };
 ```
 
-![BPMN Network Test Process](/docs/images/bpmn/BPMN_script-task-network.png)
+![BPMN Network Test Process](/images/bpmn/BPMN_script-task-network.png)

pages/bpmn/bpmn-subprocesses.mdx → pages/developer/bpmn/bpmn-subprocesses.mdx

@@ -3,13 +3,13 @@ The former are usual processes enclosed inside the parent process and don't live
 Embedded subprocesses are mainly used to reduce the visual complexity of a process.
 Therefore, they can be in an expanded and in a collapsed (with a plus symbol) state.
 
-![BPMN Process](/docs/images/bpmn/BPMN_embedded_subprocesses.png?width=700px)
+![BPMN Process](/images/bpmn/BPMN_embedded_subprocesses.png?width=700px)
 
 A call activity references another process, so that a process can be reused in multiple processes.
 For instance, a billing process is a typical example of a reusable process.
 The Call Activity is marked with a thick border and requires the referenced process to have at least one non-typed start event.
 
-![BPMN Process](/docs/images/bpmn/callactivity.png?width=400px)
+![BPMN Process](/images/bpmn/callactivity.png?width=400px)
 
 ## Embedded expanded or collapsed Subprocess