From d7a19accb29de5b601df6874f1bf3b34a017beda Mon Sep 17 00:00:00 2001 From: Taylor Downs Date: Mon, 12 Feb 2024 08:53:52 +0000 Subject: [PATCH 1/8] wip --- docs/build-for-developers/cli-intro.md | 2 +- docs/build-for-developers/jobs.md | 2 +- docs/build/credentials.md | 2 +- docs/build/steps/editing-locally.md | 6 +++--- docs/build/steps/errors.md | 2 +- docs/build/steps/{job-expressions.md => jobs.md} | 4 ++-- docs/build/steps/step-design-intro.md | 8 ++++---- docs/build/steps/step-editor.md | 6 +++--- docs/build/steps/steps.md | 6 +++--- docs/build/steps/working-with-branches.md | 4 ++-- docs/build/workflows.md | 8 ++++---- docs/deploy/options.md | 2 +- docs/design/api-discovery.md | 4 ++-- docs/design/design-overview.md | 10 +++++----- docs/design/discovery.md | 2 +- docs/design/workflow-specs.md | 8 ++++---- docs/get-started/glossary.md | 2 +- docs/get-started/home.md | 4 ++-- docs/get-started/security-compliance.md | 4 ++-- docs/get-started/terminology.md | 8 ++++---- docs/manage-projects/platform-mgmt.md | 2 +- docs/manage-users/user-credentials.md | 2 +- docs/monitor-history/activity-history.md | 6 +++--- docs/monitor-history/inspect-runs.md | 4 ++-- docs/monitor-history/troubleshooting.md | 8 ++++---- docusaurus.config.js | 11 +++++------ sidebars-main.js | 2 +- 27 files changed, 64 insertions(+), 65 deletions(-) rename docs/build/steps/{job-expressions.md => jobs.md} (99%) diff --git a/docs/build-for-developers/cli-intro.md b/docs/build-for-developers/cli-intro.md index 1f1583439d3..39eac27e8f9 100644 --- a/docs/build-for-developers/cli-intro.md +++ b/docs/build-for-developers/cli-intro.md @@ -33,7 +33,7 @@ Before you begin with the @openfn/cli, make sure to follow these simple steps: following this guide. 3. **Understand OpenFn Basics:** Have a basic understanding of OpenFn, particularly jobs and adaptors. Check out the - [Intro section](/documentation/next) on this site. + [Intro section](/documentation) on this site. --- diff --git a/docs/build-for-developers/jobs.md b/docs/build-for-developers/jobs.md index d9c8d4816a6..bc6f8891bd7 100644 --- a/docs/build-for-developers/jobs.md +++ b/docs/build-for-developers/jobs.md @@ -2,7 +2,7 @@ title: Jobs --- -Jobs define the specific series of "operations" (think: tasks or database actions) to be performed in an individual Workflow Step. See the [Steps section](/docs/build/steps/steps.md) for detailed documentation and tips for [writing Job expressions](/docs/build/steps/job-expressions.md). +Jobs define the specific series of "operations" (think: tasks or database actions) to be performed in an individual Workflow Step. See the [Steps section](/docs/build/steps/steps) for detailed documentation and tips for [writing Job expressions](/docs/build/steps/jobs). :::note diff --git a/docs/build/credentials.md b/docs/build/credentials.md index c5eba989f7c..a30f2cf0e66 100644 --- a/docs/build/credentials.md +++ b/docs/build/credentials.md @@ -18,7 +18,7 @@ Project can choose those credentials for use when defining a job. You can create a new Credential while configuring a new Step in your Workflow, or via the Settings > Credentials page. -[Read this](/documentation/next/manage-projects/manage-credentials) for more on +[Read this](/documentation/manage-projects/manage-credentials) for more on managing credentials. ### Understand the app-specific credentials diff --git a/docs/build/steps/editing-locally.md b/docs/build/steps/editing-locally.md index 2bb82af7112..fc6834e597c 100644 --- a/docs/build/steps/editing-locally.md +++ b/docs/build/steps/editing-locally.md @@ -6,10 +6,10 @@ sidebar_label: Edit Steps locally If you're a developer, you can use your favorite text editor and make changes offline, committing and pushing to GitHub. This page describes how to edit Steps locally, instead of on the platform via -[the Inspector](/documentation/next/build/steps/step-editor). +[the Inspector](/documentation/build/steps/step-editor). First, make sure that version control is set up for your Project (see -[Manage Projects](/documentation/next/manage-projects/platform-mgmt) for more on +[Manage Projects](/documentation/manage-projects/platform-mgmt) for more on configuring this). When that's all done, follow these steps on your local machine: @@ -73,4 +73,4 @@ From there, the version control integration will update changed steps in your OpenFn Project and you can test those changes on the platform. Once you're ready to start running steps and testing your changes _locally_, -head over to the [The CLI](/documentation/next/cli) docs for guidance. +head over to the [The CLI](/documentation/cli) docs for guidance. diff --git a/docs/build/steps/errors.md b/docs/build/steps/errors.md index 9d8f78b4d8d..c313f1ad1a0 100644 --- a/docs/build/steps/errors.md +++ b/docs/build/steps/errors.md @@ -81,4 +81,4 @@ exit code itself couldn't be captured by our application. ## Limits We've shifted this content to a dedicated -[limits](/documentation/next/build/limits) page. +[limits](/documentation/build/limits) page. diff --git a/docs/build/steps/job-expressions.md b/docs/build/steps/jobs.md similarity index 99% rename from docs/build/steps/job-expressions.md rename to docs/build/steps/jobs.md index 3b3bafdc7f8..cf510cbf7e9 100644 --- a/docs/build/steps/job-expressions.md +++ b/docs/build/steps/jobs.md @@ -1,5 +1,5 @@ --- -title: Write Job expressions +title: Write Jobs sidebar_label: Write Jobs --- @@ -150,7 +150,7 @@ when writing Job expressions. #### each() For more on the `each(...)` operation, see -[this page](/documentation/next/build/steps/each) and the below example. +[this page](/documentation/build/steps/each) and the below example. ```js each( diff --git a/docs/build/steps/step-design-intro.md b/docs/build/steps/step-design-intro.md index 36bc99ce0f1..43e9494cf35 100644 --- a/docs/build/steps/step-design-intro.md +++ b/docs/build/steps/step-design-intro.md @@ -8,14 +8,14 @@ Read on for a brief overview. :::tip -Check out the [Workflow Design](/documentation/next/design/design-overview) docs +Check out the [Workflow Design](/documentation/design/design-overview) docs for more details on solution design and links to templates. ::: In short, to design a Workflow Step, you will need to follow the below actions, and consider summarizing your design specifications in a -[workflow diagram](/documentation/next/design/design-workflow). +[workflow diagram](/documentation/design/design-workflow). ![Example Workflow](/img/example-workflow-state.png) @@ -29,7 +29,7 @@ and consider summarizing your design specifications in a ### 2: Map your data elements -[See here](/documentation/next/design/mapping-specs) for detailed guidance on +[See here](/documentation/design/mapping-specs) for detailed guidance on mapping data elements or "data dictionaries" between your source and destination apps. To get started: @@ -63,7 +63,7 @@ apps. To get started: - `updateTEI(...)` - `upsertTEI(...)` -See example [Job expression](/docs/build/steps/job-expressions.md) for a Step +See example [Job expression](/docs/build/steps/jobs.md) for a Step that will "upsert" (update or insert) records in a SQL database. ```js diff --git a/docs/build/steps/step-editor.md b/docs/build/steps/step-editor.md index 794e9d53bdd..02634ba145c 100644 --- a/docs/build/steps/step-editor.md +++ b/docs/build/steps/step-editor.md @@ -20,7 +20,7 @@ To access this interface: For more on how to write custom business logic and data transformation rules in the `Editor`, see the docs on -[writing Jobs](/documentation/next/build/steps/job-expressions) and check out +[writing Jobs](/documentation/build/steps/jobs) and check out the below video. @@ -40,7 +40,7 @@ include `Logs` and an `Output`. - `Logs` - A record generated by the workflow execution engine that details the activities performed when running a Workflow or individual Step. -See [Writing Jobs docs](/documentation/next/build/steps/job-expressions) for +See [Writing Jobs docs](/documentation/build/steps/jobs) for more on writing custom logic, and see -[this article](/documentation/next/build/steps/state) for more on the concept of +[this article](/documentation/build/steps/state) for more on the concept of "state" when writing Jobs and building OpenFn Workflows. diff --git a/docs/build/steps/steps.md b/docs/build/steps/steps.md index 3fbae426f9d..2483f75cfc9 100644 --- a/docs/build/steps/steps.md +++ b/docs/build/steps/steps.md @@ -34,7 +34,7 @@ A Step includes these key components: Writing Jobs to add custom logic for business or data transformation rules typically requires basic knowledge of JavaScript. See the -[Job-writing docs](/documentation/next/build/job-expressions) for a detailed +[Job-writing docs](/documentation/build/jobs) for a detailed overview and the [Library Examples](/adaptors/library) for sample code. ::: @@ -134,5 +134,5 @@ want this and to avoid the risk of accidental upgrades on live Workflows. Click the code button `` displayed on the configuration panel to write or edit a Job expression to define the "rules" or the specific tasks to be completed by your Step. See the pages on -[the Inspector](/docs/build/steps/step-editor.md) and -[writing Jobs](/docs/build/steps/job-expressions.md) to learn more. +[the Inspector](/docs/build/steps/step-editor) and +[writing Jobs](/docs/build/steps/jobs) to learn more. diff --git a/docs/build/steps/working-with-branches.md b/docs/build/steps/working-with-branches.md index 9b27189f215..636d0c20e88 100644 --- a/docs/build/steps/working-with-branches.md +++ b/docs/build/steps/working-with-branches.md @@ -3,7 +3,7 @@ title: Manage changes with Github branches sidebar_label: Manage changes --- -In the [Edit Steps Locally](/documentation/next/build/steps/editing-locally) +In the [Edit Steps Locally](/documentation/build/steps/editing-locally) section, we walked through the process of creating and adding your changes to the `main` branch of a project. @@ -28,7 +28,7 @@ repo to your local folder. branch. When you start editing your steps, the changes will be kept on this branch, managed separately from `main`. -2. To test the changes locally, check out the [The CLI](/documentation/next/cli) +2. To test the changes locally, check out the [The CLI](/documentation/cli) docs. 3. Just as you've seen when working on `main`, when you're done check which diff --git a/docs/build/workflows.md b/docs/build/workflows.md index 2e520b21573..eb686eab224 100644 --- a/docs/build/workflows.md +++ b/docs/build/workflows.md @@ -1,5 +1,5 @@ --- -title: About4. Workflows +title: Workflows sidebar_label: Workflows --- @@ -13,9 +13,9 @@ To create a new Workflow in your Project: 1. Go to the `Workflows` page. 2. Click `Create new workflow` button. 3. Give your Workflow a descriptive `Name` (e.g., `Register patients`, `Refer cases`, `Monthly payroll`). -4. Choose your [Trigger](/documentation/next/build/triggers) -5. Edit your first [Step](/documentation/next/build/step/steps) -6. Modify the [Path Condition](/documentation/next/build/paths), if needed, to define _when_ the Workflow should proceed to the next Step. +4. Choose your [Trigger](/documentation/build/triggers) +5. Edit your first [Step](/documentation/build/steps/steps) +6. Modify the [Path Condition](/documentation/build/paths), if needed, to define _when_ the Workflow should proceed to the next Step. 7. Configure more Steps as needed Check out the video overview below to learn how to create a Workflow. diff --git a/docs/deploy/options.md b/docs/deploy/options.md index be539f9f6a5..160bfaad3ea 100644 --- a/docs/deploy/options.md +++ b/docs/deploy/options.md @@ -11,7 +11,7 @@ outside your country's borders. :::success Portability -Because of OpenFn's [portability specification](/documentation/next/deploy/portability) and open-source +Because of OpenFn's [portability specification](/documentation/deploy/portability) and open-source deployment tools you can transition between these various pathways at any time. We're committed to a **no vendor lock-in** experience. diff --git a/docs/design/api-discovery.md b/docs/design/api-discovery.md index 9b722e4e7ec..6418833f3d0 100644 --- a/docs/design/api-discovery.md +++ b/docs/design/api-discovery.md @@ -70,7 +70,7 @@ Be on the lookout for API limits. Documentation will often have a dedicated sect ## Technical Workflow Diagramming -The output of API discovery should be a “technical” workflow diagram. This diagram is different from the functional workflow diagram produced during [“Discovery”](/documentation/next/design/discovery) in that it captures the technical specifications for how to integrate with target applications. These specifications include the specific methods/operations (e.g., GET, POST) and the database/API names of the target resources (i.e., specific API endpoints or database tables). +The output of API discovery should be a “technical” workflow diagram. This diagram is different from the functional workflow diagram produced during [“Discovery”](/documentation/design/discovery) in that it captures the technical specifications for how to integrate with target applications. These specifications include the specific methods/operations (e.g., GET, POST) and the database/API names of the target resources (i.e., specific API endpoints or database tables). ![Workflow](/img/api_example.png) @@ -93,6 +93,6 @@ __When drafting your technical specifications, consider the following:__ - Consider bulk operations & batching requests -Check out the technical workflow diagram below for syncing forms submissions from KoboToolBox to DHIS2. The original functional diagram can be found [here](/documentation/next/design/discovery#workflow-requirements-gathering). +Check out the technical workflow diagram below for syncing forms submissions from KoboToolBox to DHIS2. The original functional diagram can be found [here](/documentation/design/discovery#workflow-requirements-gathering). ![Workflow](/img/technical_example.png) \ No newline at end of file diff --git a/docs/design/design-overview.md b/docs/design/design-overview.md index 2b827ec727d..9e4b4b30d79 100644 --- a/docs/design/design-overview.md +++ b/docs/design/design-overview.md @@ -32,11 +32,11 @@ The process of combining data from different sources into a centralized view. Da ## Introduction Workflow automation design features 5 main steps that are covered in depth in other articles: -1. [Discovery & Scoping](/documentation/next/design/discovery) -2. [Workflow Design](/documentation/next/design/design-workflow) -3. [API Discovery and Technical Design](/documentation/next/design/api-discovery) -4. [Data Element Mapping Specifications](/documentation/next/design/mapping-specs) -5. [Workflow Specifications](/documentation/next/design/workflow-specs) +1. [Discovery & Scoping](/documentation/design/discovery) +2. [Workflow Design](/documentation/design/design-workflow) +3. [API Discovery and Technical Design](/documentation/design/api-discovery) +4. [Data Element Mapping Specifications](/documentation/design/mapping-specs) +5. [Workflow Specifications](/documentation/design/workflow-specs) ### Example Use Case Throughout the design documentation we will reference the fictional data collection & workflow automation scenario below: diff --git a/docs/design/discovery.md b/docs/design/discovery.md index 3d73d41117f..741d91df17d 100644 --- a/docs/design/discovery.md +++ b/docs/design/discovery.md @@ -6,7 +6,7 @@ title: Discovery & Scoping for OpenFn Projects # Discovery & Scoping for OpenFn Projects -This article outlines key discovery and scoping questions to confirm the business value, core workflow requirements, technical feasibility, and client capacity when starting a new implementation. This article will be referencing the example use case introduced in the [series introduction](/documentation/next/design/design-overview#example-use-case). +This article outlines key discovery and scoping questions to confirm the business value, core workflow requirements, technical feasibility, and client capacity when starting a new implementation. This article will be referencing the example use case introduced in the [series introduction](/documentation/design/design-overview#example-use-case). :::tip diff --git a/docs/design/workflow-specs.md b/docs/design/workflow-specs.md index 05719c811c1..07aac631c68 100644 --- a/docs/design/workflow-specs.md +++ b/docs/design/workflow-specs.md @@ -7,10 +7,10 @@ title: Writing Workflow Automation Specifications __The key outputs of the the design process are:__ -1. [Functional Workflow diagram](/documentation/next/design/discovery#workflow-requirements-gathering) -2. [Technical Workflow diagram](/documentation/next/design/discovery#workflow-requirements-gathering) -3. [Solution Architecture Diagram](/documentation/next/design/discovery#documenting-the-solution-architecture) -4. [Data element mapping specifications](/documentation/next/design/mapping-specs) +1. [Functional Workflow diagram](/documentation/design/discovery#workflow-requirements-gathering) +2. [Technical Workflow diagram](/documentation/design/discovery#workflow-requirements-gathering) +3. [Solution Architecture Diagram](/documentation/design/discovery#documenting-the-solution-architecture) +4. [Data element mapping specifications](/documentation/design/mapping-specs) Given these, you’ll be ready to finalize your workflow specifications and hand-off to developers for job-writing! diff --git a/docs/get-started/glossary.md b/docs/get-started/glossary.md index ed164221696..76abeab96c4 100644 --- a/docs/get-started/glossary.md +++ b/docs/get-started/glossary.md @@ -13,7 +13,7 @@ further reading if you want a better understanding of some part of your data integration picture. Note: This glossary is meant to be OpenFn-agnostic. The rest of the docs and -[Key Concepts page](/documentation/next/get-started/terminology) help you to get a +[Key Concepts page](/documentation/get-started/terminology) help you to get a picture of the parts of OpenFn, what we call them, and why, but this glossary is really meant as a prerequisite to all those other things to aid users with no experience in this area. diff --git a/docs/get-started/home.md b/docs/get-started/home.md index 858ef5ba56d..4cb971e3b2a 100644 --- a/docs/get-started/home.md +++ b/docs/get-started/home.md @@ -30,7 +30,7 @@ interoperability at all levels. OpenFn can be deployed locally or on the secure [cloud-hosted platform](https://openfn.org/pricing). See the -[Deploy docs](/documentation/next/deploy/options) for more on deployment options +[Deploy docs](/documentation/deploy/options) for more on deployment options and requirements. To support implementers, OpenFn has an online @@ -117,7 +117,7 @@ writing & testing workflows, managing OpenFn projects, and developing You can view the technical documentation and source code for OpenFn's fully open source ("FOSS") integration tools and adaptors in their respective repositories at [Github.com/OpenFn](https://github.com/openfn) or see -[Deploy](/documentation/next/deploy/options) section for an overview of the FOSS +[Deploy](/documentation/deploy/options) section for an overview of the FOSS options and additional docs. ::: diff --git a/docs/get-started/security-compliance.md b/docs/get-started/security-compliance.md index 115edf21e8b..d15cf333c18 100644 --- a/docs/get-started/security-compliance.md +++ b/docs/get-started/security-compliance.md @@ -17,7 +17,7 @@ NGOs worldwide. ✓ Build “zero-persistence” data pipelines to fully control where data is store ✓ Security implementation training & guidance for your project teams -([read more](/documentation/next/get-started/security)) +([read more](/documentation/get-started/security)) See our main website to learn more about OpenFn [Compliance](https://openfn.org/compliance) and @@ -33,7 +33,7 @@ Workflows can be configured to adhere to your organization's specific data sharing agreements and security policies. Consult the `Manage Projects` docs pages for more on project and -[data storage settings](documentation/next/manage-projects/io-data-storage). +[data storage settings](documentation/manage-projects/io-data-storage). See the below diagram for an example architecture where even the cloud-hosted OpenFn platform can be configured as a **“zero-persistence” data pipeline** to diff --git a/docs/get-started/terminology.md b/docs/get-started/terminology.md index ec63cda654e..b3d96563ce1 100644 --- a/docs/get-started/terminology.md +++ b/docs/get-started/terminology.md @@ -19,7 +19,7 @@ or ask on the [Community](https://community.openfn.org) Please note that if you're looking for a glossary for generic terms used in data-integration (rather than this _OpenFn-specific_ stuff) head over to the -[Glossary for Integration](/documentation/next/get-started/glossary) page in the +[Glossary for Integration](/documentation/get-started/glossary) page in the Design section. Otherwise, read on! ## Project @@ -31,7 +31,7 @@ workflow configuration & history. Projects have an owner and one or more Collaborators. In local deployment and development, Project also corresponds to a -[`project.yaml`](/documentation/next/deploy/portability-versions#proposal-v2) +[`project.yaml`](/documentation/deploy/portability-versions#proposal-v2) file, which defines a project' configuration. In either case, a Project contains Workflows, Triggers, Credentials, and @@ -50,7 +50,7 @@ connected together to automate a specific business process or task. A Workflow is configured via the Canvas in the web app, or locally (via code). OpenFn automation centers around -[Workflows](/documentation/next/build/workflows), which may have one or multiple +[Workflows](/documentation/build/workflows), which may have one or multiple Steps. Workflows can be run in real-time (based on an event -e.g., new patient registration), on a scheduled basis (e.g., every day at 8am), or manually on-demand. @@ -121,7 +121,7 @@ Triggers are the **"when to do it"** part of automation! A [Trigger](/documentation/build/triggers) determines **how and when** Workflows should execute automatically (e.g., real-time or schedule-based). When activated, Triggers create a new -[Work Order](/documentation/next/get-started/terminology#work-order) and run (or +[Work Order](/documentation/get-started/terminology#work-order) and run (or "execute") the Workflow. A "Webhook Event" Trigger may be configured if you want your Workflow to execute diff --git a/docs/manage-projects/platform-mgmt.md b/docs/manage-projects/platform-mgmt.md index 4c552302fc0..f6d8439c752 100644 --- a/docs/manage-projects/platform-mgmt.md +++ b/docs/manage-projects/platform-mgmt.md @@ -16,4 +16,4 @@ sidebar). Setup allows you to view or edit the project name and description. You can also export your entire project "as code" - either to save it, or to edit your project locally. You can learn more about this feature on our -[Portability page](/documentation/next/deploy/portability). +[Portability page](/documentation/deploy/portability). diff --git a/docs/manage-users/user-credentials.md b/docs/manage-users/user-credentials.md index b9312bb338a..bb92bda8eb1 100644 --- a/docs/manage-users/user-credentials.md +++ b/docs/manage-users/user-credentials.md @@ -14,7 +14,7 @@ The `Credentials` page of your `User Settings` allows you to add, view, edit or ![User Credentials List](/img/lightning_edit_user_credential.png) -For guidance on how to set up a new Credential, head over to our [Manage Credentials](/documentation/next/manage-projects/manage-credentials) page. +For guidance on how to set up a new Credential, head over to our [Manage Credentials](/documentation/manage-projects/manage-credentials) page. You can update the name and login details of a Credential after clicking `Edit`. diff --git a/docs/monitor-history/activity-history.md b/docs/monitor-history/activity-history.md index e5e9eed76e8..6ff4db1fbbd 100644 --- a/docs/monitor-history/activity-history.md +++ b/docs/monitor-history/activity-history.md @@ -10,8 +10,8 @@ components. ## History The `History` page provides a list of all of the -[Work Orders](/documentation/next/get-started/terminology#work-order) and -[Runs](/documentation/next/get-started/terminology#run) that have been processed +[Work Orders](/documentation/get-started/terminology#work-order) and +[Runs](/documentation/get-started/terminology#run) that have been processed in a Project. ![History](/img/case-referral-history.png) @@ -28,7 +28,7 @@ OpenFn Workflows are executed as follows: (without errors) - this ensures that the processing of has been completed. 3. A `Run` is then executed to try to complete the Workflow successfully. This Run will have a - [status code](/documentation/next/monitor-history/status-codes), indicating + [status code](/documentation/monitor-history/status-codes), indicating whether the Workflow Steps were successfully processed. 4. If the 1st `Run` fails, then you can rerun it to "retry" the workflow. A 2nd `Run` will be created. If successful, then both the Run and related Work diff --git a/docs/monitor-history/inspect-runs.md b/docs/monitor-history/inspect-runs.md index 10e600cd3af..e9532e89b0a 100644 --- a/docs/monitor-history/inspect-runs.md +++ b/docs/monitor-history/inspect-runs.md @@ -3,13 +3,13 @@ title: Inspect Runs & Search via the History page sidebar_label: Inspect Runs --- -A [Run](/documentation/next/get-started/terminology#run) is created each time +A [Run](/documentation/get-started/terminology#run) is created each time OpenFn attempts to excute a Workflow for a given Work Order. All Runs can be viewed, filtered, and searched via the `History` page. In short, Runs tell us "what happened" when OpenFn tried to execute the Workflow. Runs have start times, end times, logs, and -[status codes](/documentation/next/monitor-history/status-codes) that indicate +[status codes](/documentation/monitor-history/status-codes) that indicate when they took place, what they did, and whether or not they succeeded. ## Inspect Runs diff --git a/docs/monitor-history/troubleshooting.md b/docs/monitor-history/troubleshooting.md index 5ec36b35a7b..0a3495ebea9 100644 --- a/docs/monitor-history/troubleshooting.md +++ b/docs/monitor-history/troubleshooting.md @@ -8,14 +8,14 @@ sidebar_label: Troubleshooting ## Runs One of the most helpful pages for troubleshooting on OpenFn is the -[History](/documentation/next/monitor-history/activity-history) page. -This page provides a list of all of the runs executed for a Work Order and their status. Project administrators can troubleshoot errors by clicking into the run to review the run details. Learn more about runs [here](/documentation/next/monitor-history/inspect-runs) here. +[History](/documentation/monitor-history/activity-history) page. +This page provides a list of all of the runs executed for a Work Order and their status. Project administrators can troubleshoot errors by clicking into the run to review the run details. Learn more about runs [here](/documentation/monitor-history/inspect-runs) here. ### Status codes Every run will have a status code. The status code is a way for OpenFn to classify the run status and can help you troubleshoot errors. Learn more about OpenFn -status codes and what each one means [here](/documentation/next/monitor-history/status-codes). +status codes and what each one means [here](/documentation/monitor-history/status-codes). ### The time it took for the workflow to fail @@ -87,7 +87,7 @@ Leverage the various search functionalities in OpenFn to find the right runs to ## Sign up for email alerts -You can turn on notifications to receive [email alerts](/documentation/next/manage-projects/notifications) when a workflow fails and subscribe to digests that summarize project activity. +You can turn on notifications to receive [email alerts](/documentation/manage-projects/notifications) when a workflow fails and subscribe to digests that summarize project activity. ## More diff --git a/docusaurus.config.js b/docusaurus.config.js index e42bcf43ece..ed7ffa063dd 100644 --- a/docusaurus.config.js +++ b/docusaurus.config.js @@ -34,7 +34,7 @@ module.exports = { { type: 'doc', position: 'left', - docId: 'intro/home', + docId: 'get-started/home', label: 'Docs', }, { @@ -136,15 +136,14 @@ module.exports = { sidebarPath: require.resolve('./sidebars-main.js'), routeBasePath: '/documentation', editUrl: 'https://github.com/openfn/docs/edit/main', - lastVersion: 'legacy', + lastVersion: 'current', versions: { current: { - banner: 'unreleased', - label: 'Lightning 🚧', + label: 'v2 ⚡', }, legacy: { - banner: 'none', - label: 'Platform (v1)', + banner: 'unmaintained', + label: 'v1.105', }, }, }, diff --git a/sidebars-main.js b/sidebars-main.js index ae5bc6ba34c..74bfaf0cd02 100644 --- a/sidebars-main.js +++ b/sidebars-main.js @@ -49,7 +49,7 @@ module.exports = { type: 'category', label: 'Jobs', items: [ - 'build/steps/job-expressions', + 'build/steps/jobs', 'build/steps/job-examples', 'build/steps/operations', 'build/steps/multiple-operations', From 1fdf4a915edc002f7e2d0e58ed6f38cabc802208 Mon Sep 17 00:00:00 2001 From: aleksa-krolls Date: Mon, 12 Feb 2024 17:22:48 +0200 Subject: [PATCH 2/8] updating links in legacy docs --- adaptors/commcare.md | 2 +- articles/2021-05-24-commcare-events.md | 6 ++--- ...2021-07-05-wrapping-my-head-around-jobs.md | 2 +- ...script-helped-me-better-understand-jobs.md | 4 +-- articles/2022-09-19-auth-security.md | 2 +- blog/2021-03-30-digital-global-good.md | 4 +-- ...-30-processes-and-open-source-as-choice.md | 2 +- blog/2023-04-13-lightning-beta.md | 4 +-- blog/2023-08-14-OS4H-case-study.md | 2 +- docs/build/steps/steps.md | 2 +- docs/build/triggers.md | 26 +++++++++++-------- docs/contribute/openfn-roadmap.md | 6 ++--- docs/deploy/portability-versions.md | 2 +- docs/design/overview.md | 4 +-- docs/get-started/glossary.md | 2 +- docs/get-started/implementation-checklist.md | 6 ++--- docs/get-started/security.md | 2 +- .../troubleshooting-tips-on-platform.md | 14 +++++----- .../version-legacy/about-lightning.md | 8 +++--- .../version-legacy/build/example-build.md | 2 +- versioned_docs/version-legacy/build/inbox.md | 2 +- versioned_docs/version-legacy/build/jobs.md | 2 +- .../build/lightning-quick-start.md | 2 +- versioned_docs/version-legacy/cli.md | 4 +-- .../design/design-quickstart.md | 4 +-- .../version-legacy/devtools/home.md | 2 +- .../commcare-project-walkthrough.md | 10 +++---- .../getting-started/glossary.md | 2 +- .../implementation-checklist.md | 6 ++--- .../getting-started/integration-toolkit.md | 2 +- .../getting-started/security.md | 2 +- .../so-you-want-to-integrate.mdx | 4 +-- .../getting-started/terminology.md | 14 +++++----- .../version-legacy/instant-openhie.md | 10 +++---- versioned_docs/version-legacy/intro/home.md | 4 +-- .../version-legacy/jobs/editing_locally.md | 2 +- .../version-legacy/jobs/job-design-intro.md | 2 +- .../version-legacy/jobs/job-studio.md | 4 +-- .../version-legacy/manage/platform-mgmt.md | 14 +++++----- .../troubleshooting-tips-on-platform.md | 14 +++++----- .../version-legacy/openfn-roadmap.md | 6 ++--- .../version-legacy/portability-versions.md | 2 +- 42 files changed, 110 insertions(+), 106 deletions(-) diff --git a/adaptors/commcare.md b/adaptors/commcare.md index 7743c2ff07b..4c0f167742c 100644 --- a/adaptors/commcare.md +++ b/adaptors/commcare.md @@ -96,7 +96,7 @@ integration and mapping data elements. case (i.e. person, event, etc) search by `case id`. ![image](https://user-images.githubusercontent.com/80456839/128649444-04f371ea-80b1-4c28-8d42-1591c0a96758.png) -- In the OpenFn [message](/documentation/getting-started/terminology#message): +- In the OpenFn [message](/documentation/get-started/terminology#message): `id` is the unique identifier for the form submission ![image](https://user-images.githubusercontent.com/80456839/128649481-83b3f7ee-c6a6-42f8-8752-2f4e96b7fa1f.png) diff --git a/articles/2021-05-24-commcare-events.md b/articles/2021-05-24-commcare-events.md index b05b7800f7b..b94ed1e6887 100644 --- a/articles/2021-05-24-commcare-events.md +++ b/articles/2021-05-24-commcare-events.md @@ -372,9 +372,9 @@ this all up on your own are: 2. the [forum](https://community.openfn.org) (community.openfn.org) Read through the -["What is an integration"](/documentation/getting-started/so-you-want-to-integrate), -["OpenFn Concepts"](/documentation/getting-started/terminology), and -["Build"](/documentation/build/jobs) sections if you're a thorough, +["What is an integration"](/documentation/tutorials/tutorial), +["OpenFn Concepts"](/documentation/get-started/terminology), and +["Build"](/documentation/build/workflows) sections if you're a thorough, background-first kind of learner. If you crave snippets and sample job code, head directly to the [Job Library](/adaptors/library) to see how other OpenFn users are creating their jobs. diff --git a/articles/2021-07-05-wrapping-my-head-around-jobs.md b/articles/2021-07-05-wrapping-my-head-around-jobs.md index 4f558725e91..8c22b7272bb 100644 --- a/articles/2021-07-05-wrapping-my-head-around-jobs.md +++ b/articles/2021-07-05-wrapping-my-head-around-jobs.md @@ -86,7 +86,7 @@ And for a fail triggered job like this: ``` No matter what, jobs start with state. See -["Initial and final state for runs"](/documentation/jobs/state/) for a detailed +["Initial and final state for runs"](/documentation/build/steps/state/) for a detailed breakdown. ## It ends with `state` too diff --git a/articles/2021-10-29-how-learning-javascript-helped-me-better-understand-jobs.md b/articles/2021-10-29-how-learning-javascript-helped-me-better-understand-jobs.md index e680ad0400f..23c6e77d575 100644 --- a/articles/2021-10-29-how-learning-javascript-helped-me-better-understand-jobs.md +++ b/articles/2021-10-29-how-learning-javascript-helped-me-better-understand-jobs.md @@ -8,7 +8,7 @@ tags: [javascript, tips, jobs, learning] featured: true --- -OpenFn automation happens via [jobs](/documentation/build/jobs) which define +OpenFn automation happens via [jobs](/documentation/build/workflows) which define specific steps ("operations") that OpenFn should perform. They're written in a [scripting language](https://www.openfn.org/core) that runs on top of (and has full access to) **Javascript**. A basic understanding of Javascript will take @@ -99,7 +99,7 @@ phase of integration design, we often discuss how each answer choice for **picklist** values should map from the source system to the destination system. Sometimes the mapping is simple but other times, there is an extensive list of possible choices that can be found in the -[message](/documentation/getting-started/terminology/#message) and not all are +[message](/documentation/get-started/terminology/#message) and not all are relevant to the destination system. Then the question is, **how should the job handle values which are not explicitly mapped?** diff --git a/articles/2022-09-19-auth-security.md b/articles/2022-09-19-auth-security.md index 616f935eee1..9f2195e68fe 100644 --- a/articles/2022-09-19-auth-security.md +++ b/articles/2022-09-19-auth-security.md @@ -57,7 +57,7 @@ to implement such security features down the line. As product manager at Open Function Group, I myself have recently been reviewing and analyzing numerous resources to identify and prioritize features required to get to fully-secure authentication and authorization for our newest product -[Lightning](/documentation/about-lightning/)–and make sure that nothing falls +[Lightning](/documentation#openfn-v2-lightning-/)–and make sure that nothing falls through the cracks. I’ve also had the opportunity to gather insights from Digital Public Good community forums (OpenMRS, DHIS2, OpenLMIS, etc) and speak to other product managers and engineers from the Digital Public Goods community diff --git a/blog/2021-03-30-digital-global-good.md b/blog/2021-03-30-digital-global-good.md index b4f0a8ee296..776f292163a 100644 --- a/blog/2021-03-30-digital-global-good.md +++ b/blog/2021-03-30-digital-global-good.md @@ -100,7 +100,7 @@ platform and our open source project have a symbiotic relationship with one another. Open source innovation drives platform innovation and vice versa. Crucially, both rely on each other. -With a more robust [open source offering ](/documentation/microservice/home)and +With a more robust [open source offering ](/documentation/deploy/portability)and a heavy investment in documentation, it will be easier than ever for organizations to get up and running with OpenFn and then choose whether they want to scale their solutions on the platform or deploy them on their own @@ -140,7 +140,7 @@ system that users can grow and mature with. While our enterprise platform might be right for your organization today, 5 years from now, once your organization has its own dedicated IT team and server infrastructure, local deployment via microservice might make better sense. The good news is that OpenFn integration -[portability](/documentation/portability) will make these transitions easy. Your +[portability](/documentation/deploy/portability) will make these transitions easy. Your integration will run just as well on your servers as ours. As the diagram below demonstrates we envision two main pathways for OpenFn diff --git a/blog/2021-07-30-processes-and-open-source-as-choice.md b/blog/2021-07-30-processes-and-open-source-as-choice.md index 7bd1ed6bc78..76ad1b3d37e 100644 --- a/blog/2021-07-30-processes-and-open-source-as-choice.md +++ b/blog/2021-07-30-processes-and-open-source-as-choice.md @@ -70,7 +70,7 @@ writes that implementing OpenFn is “changing the way they work”. The “aha” moment for those involved in this project was that the artifacts produced in an OpenFn implementation—actual [“triggers”](/documentation/build/triggers) and -[“jobs”](/documentation/build/jobs) written with and for the Open Source +[“jobs”](/documentation/build/workflows) written with and for the Open Source Integration Toolkit—publicly memorialize the data sharing agreements between partners. diff --git a/blog/2023-04-13-lightning-beta.md b/blog/2023-04-13-lightning-beta.md index 96102e38eb8..bcd4c5df7f1 100644 --- a/blog/2023-04-13-lightning-beta.md +++ b/blog/2023-04-13-lightning-beta.md @@ -21,7 +21,7 @@ intuitive, user-friendly UI. **Read more about Lightning on our -[docs page](/documentation/about-lightning).** +[docs page](/documentation#openfn-v2-lightning-).** :::info @@ -72,7 +72,7 @@ Take 2 minutes to click around the app and view all of the different pages. As you click into them, tell us where your attention is drawn and what you think each page might be for. -** 3. Using the [quick-start guide](/documentation/build/lightning-quick-start), +** 3. Using the [quick-start guide](/documentation/tutorials/tutorial), figure out how OpenFn works and what you can do in the application.** ** 4. Now, in your own words, explain to someone how to build a workflow.** diff --git a/blog/2023-08-14-OS4H-case-study.md b/blog/2023-08-14-OS4H-case-study.md index 38653489ca1..0589a6cbcda 100644 --- a/blog/2023-08-14-OS4H-case-study.md +++ b/blog/2023-08-14-OS4H-case-study.md @@ -75,7 +75,7 @@ These users might not even be aware that OpenFn is engine powering the workflow | *Above: Screenshot from online meeting with Taylor Downs (OpenFn) and Clem Francis (Developer, OS4H) celebrating the successful setup of an OpenFn workflow that automates calculating and reporting aggregated data values for key indicators to DHIS2.*| ## What's next? -In April 2023, OS4H successfully launched the DHIS2 dashboard solution and handed over the monitoring of the OpenFn automation to the St. Lucia MOH team for the duration of the pilot. In the coming months, the St. Lucia MOH and OS4H will consider adding functionality and deploying the solution on a local, ministry-managed server, using [OpenFn Lightning](https://docs.openfn.org/documentation/about-lightning) (the OpenFn “v2” fully open-source web app) for continued use at a greater scale. +In April 2023, OS4H successfully launched the DHIS2 dashboard solution and handed over the monitoring of the OpenFn automation to the St. Lucia MOH team for the duration of the pilot. In the coming months, the St. Lucia MOH and OS4H will consider adding functionality and deploying the solution on a local, ministry-managed server, using [OpenFn Lightning](https://docs.openfn.org/documentation#openfn-v2-lightning-) (the OpenFn “v2” fully open-source web app) for continued use at a greater scale. In the meantime, the OS4H team is continuing to deliver transformative digital solutions for partners across the Caribbean and is lining up its next OpenFn project. diff --git a/docs/build/steps/steps.md b/docs/build/steps/steps.md index 2483f75cfc9..953a738ad48 100644 --- a/docs/build/steps/steps.md +++ b/docs/build/steps/steps.md @@ -34,7 +34,7 @@ A Step includes these key components: Writing Jobs to add custom logic for business or data transformation rules typically requires basic knowledge of JavaScript. See the -[Job-writing docs](/documentation/build/jobs) for a detailed +[Job-writing docs](/documentation/build/workflows) for a detailed overview and the [Library Examples](/adaptors/library) for sample code. ::: diff --git a/docs/build/triggers.md b/docs/build/triggers.md index 4301a60f9cf..32fa7a88004 100644 --- a/docs/build/triggers.md +++ b/docs/build/triggers.md @@ -21,17 +21,21 @@ real-time event-based automation. ### Cron Triggers (formerly timers) -`Cron Triggers` run Workflows based on a cron schedule, and are good for repetitive tasks that are time-based (e.g., every day at 8am, sync financial data). +`Cron Triggers` run Workflows based on a cron schedule, and are good for +repetitive tasks that are time-based (e.g., every day at 8am, sync financial +data). + - These Triggers enable users to “pull” data from connected systems. -- You can pick a standard schedule (e.g., every day, or every month), or define a custom schedule using cron expressions. +- You can pick a standard schedule (e.g., every day, or every month), or define + a custom schedule using cron expressions. -These Triggers enable Workflows to be run as frequently as -once every minutes, or as infrequently as you desire and can be scheuled on very -specific dates or times. +These Triggers enable Workflows to be run as frequently as once every minutes, +or as infrequently as you desire and can be scheuled on very specific dates or +times. -Each time a timed job succeeds, its `final_state` will -be saved and used as the `initial_state` for its next run. See "Managing state" -and "Keeping a cursor" below for implementation help. +Each time a timed job succeeds, its `final_state` will be saved and used as the +`initial_state` for its next run. See "Managing state" and "Keeping a cursor" +below for implementation help. ![Cron Trigger](/img/cron_trigger.png) @@ -45,9 +49,9 @@ the OpenFn interface or #### Managing the size of `state` for Cron Workflows -Since state is passed between each run of a cron Workflow, if your Workflow Step adds -something new to state each time it runs, it may quickly become too large to be -practically handled. Imagine if a server response were adding, via +Since state is passed between each run of a cron Workflow, if your Workflow Step +adds something new to state each time it runs, it may quickly become too large +to be practically handled. Imagine if a server response were adding, via `array.push(...)`, to `state.references` each time the job ran. OpenFn supports up to 50,000 bytes (via Erlang's `byte_size`), though most `final_state` byte sizes are between 100 and 1000. diff --git a/docs/contribute/openfn-roadmap.md b/docs/contribute/openfn-roadmap.md index 4c39eaf3c8c..a1ce42be97b 100644 --- a/docs/contribute/openfn-roadmap.md +++ b/docs/contribute/openfn-roadmap.md @@ -26,7 +26,7 @@ product suite. This includes OpenFn/`Lightning`, `Adaptors`, and `Docs`. OpenFn/Lightning is the fully open-source workflow automation platform at the core of the OpenFn Digital Public Good (learn more about the product -[here](/documentation/about-lightning)). +[here](/documentation#openfn-v2-lightning-)). | **Feature** | **`Status`** | **Target Timeline** | **Related Links** | **Description** | | ---------------------------------------------------------------------- | ------------ | ------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | @@ -59,7 +59,7 @@ workflow engine, enable automated workflows that cut across digital systems. | **Feature** | **`Status`** | **Target Timeline** | **Related Links** | **Description** | | ------------------------------------------------------------------------------------------------- | ------------ | ------------------- | ------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| 1. Enhancements to [`FHIR`](http://www.hl7.org/fhir/) & [`OpenHIM`](http://openhim.org/) adaptors | Not Started | Q3 2023 | See existing adaptors for [FHIR](/adaptors/packages/fhir-docs) and [OpenHIM](/adaptors/packages/openhim-docs) | To rebuild the existing 2021 [OpenFn Instant-OpenHIE reference demo](/documentation/instant-openhie) to highlight the exchange of data between existing non-FHIR digital health tools and a HAPI FHIR server. (OpenFn Lightning is OpenHIE-compliant and can be used as a workflow engine for the OpenHIE Interoperability layer - [learn more here](/documentation/about-lightning#standards-and-compliance-matter).) We also want to demonstrate data exchange between existing non-FHIR digital health tools and key components of Google’s [Open Health Stack](https://developers.google.com/open-health-stack) and [Cloud Healthcare API](https://cloud.google.com/healthcare-api/docs/concepts/fhir) | +| 1. Enhancements to [`FHIR`](http://www.hl7.org/fhir/) & [`OpenHIM`](http://openhim.org/) adaptors | Not Started | Q3 2023 | See existing adaptors for [FHIR](/adaptors/packages/fhir-docs) and [OpenHIM](/adaptors/packages/openhim-docs) | To rebuild the existing 2021 [OpenFn Instant-OpenHIE reference demo](/documentation/get-started/standards#openhie-standard-architecture) to highlight the exchange of data between existing non-FHIR digital health tools and a HAPI FHIR server. (OpenFn Lightning is OpenHIE-compliant and can be used as a workflow engine for the OpenHIE Interoperability layer - [learn more here](/documentation#openfn-v2-lightning-#standards-and-compliance-matter).) We also want to demonstrate data exchange between existing non-FHIR digital health tools and key components of Google’s [Open Health Stack](https://developers.google.com/open-health-stack) and [Cloud Healthcare API](https://cloud.google.com/healthcare-api/docs/concepts/fhir) | | 2. Add "magic" functions to existing, in-demand adaptors | Not started | Q3 2023 | [Issue 243](https://github.com/OpenFn/adaptors/issues/243) | Add functions, dynamic lists, and shortcuts to fast-track workflow configuration for key adaptors including HTTP, [DHIS2](https://dhis2.org/), [CommCare](https://www.dimagi.com/commcare/), & [OpenMRS](https://openmrs.org/) | | 3. New [`OpenMRS`](https://openmrs.org/) adaptor version | Not started | Q3 2023 | [See existing adaptor docs](/adaptors/packages/openmrs-readme) | To ensure compliance with OpenMRS v3 | | 4. Enhancements to the [`OCL`](https://openconceptlab.org/) adaptor | Not started | Q3 2023 | [See existing adaptor docs](/adaptors/packages/ocl-readme) | To ensure that mappings stored in OCLs can be more easily access and processed as inputs in OpenFn/Lightning workflows | @@ -68,7 +68,7 @@ workflow engine, enable automated workflows that cut across digital systems. | **Feature** | **`Status`** | **Target Timeline** | **Related Links** | **Description** | | ----------------------------------------------------------- | ------------ | ------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| 1. OpenFn and the [OpenHIE](https://ohie.org/) architecture | Planned | Q2 2023 | [See current docs](/documentation/about-lightning#standards-and-compliance-matter) | New page dedicated to how OpenHIE aligns with OpenHIE architecture; expansion of the existing small section on standards | +| 1. OpenFn and the [OpenHIE](https://ohie.org/) architecture | Planned | Q2 2023 | [See current docs](/documentation#openfn-v2-lightning-#standards-and-compliance-matter) | New page dedicated to how OpenHIE aligns with OpenHIE architecture; expansion of the existing small section on standards | | 2. New Lightning User Guidance | Not started | Q3 2023 | To be hosted on docs.openfn.org | New documentation, videos, and other user guidance on how to use OpenFn/Lightning and how to migrate existing OpenFn/platform projects to Lightning (the new OpenFn "v2") | | 3. Template [FHIR](http://www.hl7.org/fhir/) Workflows | Planned | Q3 2023 | To be hosted on demo.openfn.org | OpenFn can already help achieve FHIR compliance, but we will build and document reference/template workflows to demonstrate how OpenFn/Lightning can automate data exchange, registration, and/or reporting workflows between non-FHIR data systems and FHIR APIs. | | 4. Template Alerting Workflows | Not started | Q4 2023 | [See OpenHIE docs](https://guides.ohie.org/arch-spec/introduction/alerting-sending-reminders-or-information); to be hosted on demo.openfn.org | To demonstrate how OpenFn can facilitate one-way communication to a client or provider listed in the HIE (from the OpenHIE standard spec) | diff --git a/docs/deploy/portability-versions.md b/docs/deploy/portability-versions.md index f824370d7ba..aef89fad1fb 100644 --- a/docs/deploy/portability-versions.md +++ b/docs/deploy/portability-versions.md @@ -10,7 +10,7 @@ be used to import or export projects between OpenFn/platform and OpenFn/engine. The portability specification v4 defines how entire projects (groups of workflows with their associated triggers, credentials and jobs) can be represented as code. This specification has been written for -[Lightning](/documentation/getting-started/integration-toolkit/#lightning-coming-soon), +[Lightning](/documentation#our-products/#lightning-coming-soon), the fully open source webb app which extends the OpenFn DPG. It aims to (a) improve developer experience, allowing them to build and test workflows locally; (b) enable version control and an audit trail of project changes; and (c) enable diff --git a/docs/design/overview.md b/docs/design/overview.md index a4fe4a5e1c7..0a044ac8311 100644 --- a/docs/design/overview.md +++ b/docs/design/overview.md @@ -76,7 +76,7 @@ information will be exchanged? With _whom_ (between which systems or users)? _When_ will the information be exchanged? And what are the human or automation steps that should facilitate and trigger this exchange? These business process questions are discussed in more detail on the -[So, what is an integration?](/documentation/getting-started/so-you-want-to-integrate/) +[So, what is an integration?](/documentation/tutorials/tutorial/) page. :::tip @@ -196,5 +196,5 @@ solution, as well as memorialize the business decisions and agreements made by implementing partners. Share this documentation with any technical implementation team, or check out -the [Build](/documentation/build/jobs) documentation section to learn how to +the [Build](/documentation/build/workflows) documentation section to learn how to implement these design specifications using OpenFn. \ No newline at end of file diff --git a/docs/get-started/glossary.md b/docs/get-started/glossary.md index 76abeab96c4..87b1dc45b9d 100644 --- a/docs/get-started/glossary.md +++ b/docs/get-started/glossary.md @@ -133,7 +133,7 @@ data to a destination system. ## Webhook -A [webhook](/documentation/source-apps#standard-webhook-configuration) (also +A [webhook](/documentation/legacy/source-apps#standard-webhook-configuration) (also called a web callback or HTTP push API — thanks [SendGrid](https://sendgrid.com/blog/whats-webhook/)!) is a feature of an application that allows pushing. It's often configured to notify some diff --git a/docs/get-started/implementation-checklist.md b/docs/get-started/implementation-checklist.md index 88793ae2348..d328fbfb5cf 100644 --- a/docs/get-started/implementation-checklist.md +++ b/docs/get-started/implementation-checklist.md @@ -44,11 +44,11 @@ The XLS version of this template can be found [here](https://docs.google.com/spr ## (2) Discovery & Design - Functional Workflow Requirements - [ ] User stories documented to capture business value & desired outcomes - Learn more about user stories [here.](https://docs.openfn.org/documentation/design/design-quickstart#1-capture-requirements-as-user-stories) + Learn more about user stories [here.](https://docs.openfn.org/documentation/design/design-overview#1-capture-requirements-as-user-stories) - [ ] Workflow BPMN diagram capturing functional steps of the business process finalized - Learn more about diagrams & BPMN notation [here.](https://docs.openfn.org/documentation/design/design-quickstart#2-diagram-the-business-process) + Learn more about diagrams & BPMN notation [here.](https://docs.openfn.org/documentation/design/design-overview#2-diagram-the-business-process) - [ ] Request list of data elements from administrators of target systems - Read about mapping specs [here.](https://docs.openfn.org/documentation/design/design-quickstart#3-map-data-elements-to-be-exchanged). + Read about mapping specs [here.](https://docs.openfn.org/documentation/design/design-overview#3-map-data-elements-to-be-exchanged). - [ ] Data element mapping specifications finalized (functional/business-friendly version) - [ ] Client sign-offs on workflow diagram & mapping specs - [ ] Workflow assumptions documented (e.g., what human, manual steps does the workflow rely on; what are the unique identifiers) diff --git a/docs/get-started/security.md b/docs/get-started/security.md index da95c284b74..5882af6d0f6 100644 --- a/docs/get-started/security.md +++ b/docs/get-started/security.md @@ -103,7 +103,7 @@ Here are the key OpenFn templates and resources referenced in the Guidebook: - [Mapping Specification Template](https://docs.google.com/spreadsheets/d/1IqTIgOzyOztEevXbgY_4uE8Y8tiHXufZXx-IyJZase0/edit#gid=1822444315) - [Solution Architecture Diagram](https://lucid.app/lucidchart/1e997197-2d67-4393-8394-a532d83561b2/edit#?templateid=fb96ae05-e288-4d1f-b3fc-2cbf7641a7cc) -- [BPMN Diagram resources](/documentation/design/design-quickstart/#use-bpmn-for-standardized-documentation) +- [BPMN Diagram resources](/documentation/design/design-overview/#use-bpmn-for-standardized-documentation) - [Project Security Configuration & Go-Live Checklist](https://docs.google.com/document/d/1CbQkN7SqNmXeqt3nMTYP4ioQlTuwF2LbDkkFqhp0zsU/edit?usp=sharing) ### Communities of practice & other experts diff --git a/docs/manage-projects/troubleshooting-tips-on-platform.md b/docs/manage-projects/troubleshooting-tips-on-platform.md index c9ba921ac21..e34a2fcf05e 100644 --- a/docs/manage-projects/troubleshooting-tips-on-platform.md +++ b/docs/manage-projects/troubleshooting-tips-on-platform.md @@ -12,7 +12,7 @@ Currently, this section is specific to **OpenFn/platform**. ## Runs One of the most helpful pages for troubleshooting on OpenFn platform is the -[Activity History](/documentation/getting-started/terminology/#activity-history). +[Activity History](/documentation/get-started/terminology/#activity-history). This pages provides a list of all of the runs executed in a project and always marks any failed runs red or yellow. Project administrators can troubleshoot errors by clicking into the run to review the run details. Keep reading for all @@ -23,7 +23,7 @@ troubleshooting! Every run will have an exit code. The exit code is a way for OpenFn to classify the run status and can help you troubleshoot errors. Learn more about OpenFn -exit codes and what each one means [here](/documentation/jobs/errors). +exit codes and what each one means [here](/documentation/monitor-history/troubleshooting). ### The time it took for the job to fail @@ -95,22 +95,22 @@ Leverage the various search functionalities in OpenFn to find the right messages and runs to support your troubleshooting. You can search in the Inbox, Activity History, and Search Console. -1. **[Inbox](/documentation/manage/platform-mgmt/#inbox)** - The inbox contains +1. **[Inbox](/documentation/legacy/manage/platform-mgmt/#inbox)** - The inbox contains all the messages that have been sent to your project. Search your project inbox for messages that contain a specific body text. You can also filter these messages by date, run status and trigger. You can even use filtering to see all the messages whose last run failed, so you can get to troubleshooting! Learn more about inbox filtering - [here](/documentation/manage/platform-mgmt/#inbox). + [here](/documentation/legacy/manage/platform-mgmt/#inbox). -2. **[Activity history](/documentation/getting-started/terminology/#activity-history)** - +2. **[Activity history](/documentation/get-started/terminology/#activity-history)** - As discussed above, the activity history records all runs for the current project. It has similar search and filtering capabilities as the inbox except it doesn't require valid JSON in the search box. Use the search in activity history instead of inbox when you want to search **_run logs_** instead of messages. -3. **[Search console](/documentation/manage/platform-mgmt/#search-console)** - +3. **[Search console](/documentation/legacy/manage/platform-mgmt/#search-console)** - The search console will search in both message bodies **_and_** run logs for any string is entered! @@ -123,7 +123,7 @@ leverage **bulk reprocessing** in the OpenFn inbox and activity history to reprocess all messages in the current filtered query. This means OpenFn will rerun all of those transactions in the order they were received. Learn more about bulk reprocessing -[here](/documentation/manage/platform-mgmt/#bulk-reprocess-messages). +[here](/documentation/legacy/manage/platform-mgmt/#bulk-reprocess-messages). Sometimes you'll have so many messages with failed runs that it will be virtually impossible to open each one and inspect the run logs. In this case, diff --git a/versioned_docs/version-legacy/about-lightning.md b/versioned_docs/version-legacy/about-lightning.md index c8a92f13afc..c422fdc5da9 100644 --- a/versioned_docs/version-legacy/about-lightning.md +++ b/versioned_docs/version-legacy/about-lightning.md @@ -14,7 +14,7 @@ connect _any system_. Lightning brings together the tried and tested technology which we have been using since 2015 (the OpenFn -[Integration Toolkit](/documentation/getting-started/integration-toolkit)) to +[Integration Toolkit](/documentation#our-products)) to manage the orchestration and execution of integrations in a stable, scalable and secure way. @@ -87,7 +87,7 @@ integrations to make sure no request goes unprocessed. ## Roadmap -See the [Lightning Roadmap](/documentation/openfn-roadmap) for a detailed list +See the [Lightning Roadmap](/documentation/contribute/openfn-roadmap) for a detailed list of features that are in the backlog, planned, and/or in development for the OpenFn Digital Public Good. @@ -144,7 +144,7 @@ workflow engine. Learn more via the following resources: - Check out OpenFn's entry in the [OpenHIE Reference Technologies page](https://wiki.ohie.org/display/documents/Reference+Technologies). - Explore the OpenFn-Instant OpenHIE - [reference demo implementation](/documentation/instant-openhie). + [reference demo implementation](/documentation/get-started/standards#openhie-standard-architecture). - Learn more about the GovStack [Workflow Building Block](https://govstack.gitbook.io/bb-workflow/2-description) specification. @@ -322,7 +322,7 @@ location—guaranteeing that no data ever leaves the selected country. To help our users adopt best practices when it comes to the design of their integrations, we’ve published a -[Security Guidebook for data integration implementations](/documentation/getting-started/security). +[Security Guidebook for data integration implementations](/documentation/get-started/security). ## Get involved diff --git a/versioned_docs/version-legacy/build/example-build.md b/versioned_docs/version-legacy/build/example-build.md index b182ca7486e..fbf659a370d 100644 --- a/versioned_docs/version-legacy/build/example-build.md +++ b/versioned_docs/version-legacy/build/example-build.md @@ -139,7 +139,7 @@ snippet comes into your inbox. Save your trigger. You should see a confirmation message “Found x matching messages”. To see the data from your last message inside the -[initial state](/documentation/jobs/state/#initial-state), drag the +[initial state](/documentation/build/steps/state/#initial-state), drag the **Expression** panel to the right. ![trigger message](/img/4.3_trigger_message.png 'View a matching trigger message in initial state') diff --git a/versioned_docs/version-legacy/build/inbox.md b/versioned_docs/version-legacy/build/inbox.md index 389ae51b8d8..b265bb90c7b 100644 --- a/versioned_docs/version-legacy/build/inbox.md +++ b/versioned_docs/version-legacy/build/inbox.md @@ -58,7 +58,7 @@ operations in step 4 completed successfully (what do you count as a success with these various custom actions, by the way?) you should consider implementing a SAGA pattern, whereby after all this processing is complete you trigger another request back to the initial system reporting on the downstream tasks. This can -be done in OpenFn with [Flow Triggers](/documentation/jobs/multiple-operations). +be done in OpenFn with [Flow Triggers](/documentation/build/steps/multiple-operationss). ## Synchronous vs. Asynchronous Processing diff --git a/versioned_docs/version-legacy/build/jobs.md b/versioned_docs/version-legacy/build/jobs.md index 6ae92379689..eb2eaef7628 100644 --- a/versioned_docs/version-legacy/build/jobs.md +++ b/versioned_docs/version-legacy/build/jobs.md @@ -207,7 +207,7 @@ language-packs. #### each() -Read more about each here: [The each(...) operation](/documentation/jobs/each) +Read more about each here: [The each(...) operation](/documentation/build/steps/each) ```js each( diff --git a/versioned_docs/version-legacy/build/lightning-quick-start.md b/versioned_docs/version-legacy/build/lightning-quick-start.md index eecff033e2f..252da254ffe 100644 --- a/versioned_docs/version-legacy/build/lightning-quick-start.md +++ b/versioned_docs/version-legacy/build/lightning-quick-start.md @@ -128,7 +128,7 @@ state (which contains your input) to use. When you need to use data that comes from your webhook trigger (data sent from your external system), cron trigger, or a previous job you can find it in -`state`. Learn more [here](https://docs.openfn.org/documentation/jobs/state/). +`state`. Learn more [here](https://docs.openfn.org/documentation/build/steps/state/). ::: diff --git a/versioned_docs/version-legacy/cli.md b/versioned_docs/version-legacy/cli.md index 3ca71e308d0..a88916192e8 100644 --- a/versioned_docs/version-legacy/cli.md +++ b/versioned_docs/version-legacy/cli.md @@ -39,8 +39,8 @@ to use and understand OpenFn. :::caution Looking for a way to execute jobs from OpenFn v1 locally? Use Core! If you're looking for a way to execute jobs running on the OpenFn v1 platform, -please see the documentation for **[@openfn/core](/documentation/core)** and -[Devtools](/documentation/devtools/home). +please see the documentation for **[@openfn/core](/https://github.com/OpenFn/core)** and +[Devtools](https://github.com/OpenFn/devtools). ::: diff --git a/versioned_docs/version-legacy/design/design-quickstart.md b/versioned_docs/version-legacy/design/design-quickstart.md index 21791e27d2d..7c4184200bd 100644 --- a/versioned_docs/version-legacy/design/design-quickstart.md +++ b/versioned_docs/version-legacy/design/design-quickstart.md @@ -69,7 +69,7 @@ information will be exchanged? With _whom_ (between which systems or users)? _When_ will the information be exchanged? And what are the human or automation steps that should facilitate and trigger this exchange? These business process questions are discussed in more detail on the -[So, what is an integration?](/documentation/getting-started/so-you-want-to-integrate/) +[So, what is an integration?](/documentation/tutorials/tutorial/) page. :::tip @@ -189,5 +189,5 @@ solution, as well as memorialize the business decisions and agreements made by implementing partners. Share this documentation with any technical implementation team, or check out -the [Build](/documentation/build/jobs) documentation section to learn how to +the [Build](/documentation/build/workflows) documentation section to learn how to implement these design specifications using OpenFn. diff --git a/versioned_docs/version-legacy/devtools/home.md b/versioned_docs/version-legacy/devtools/home.md index df6f670975b..98db81af208 100644 --- a/versioned_docs/version-legacy/devtools/home.md +++ b/versioned_docs/version-legacy/devtools/home.md @@ -22,7 +22,7 @@ The [Devtools](https://github.com/OpenFn/devtools) repo is a collection of bash and Node scripts, as well as a _suggested_ (but not necessary) directory structure for working with OpenFn jobs and adaptors. -To run OpenFn jobs locally, you only need [Core](/documentation/core) and at +To run OpenFn jobs locally, you only need [Core](/https://github.com/OpenFn/core) and at least one adaptor, e.g. [language-http](https://github.com/OpenFn/language-http) and you may prefer to install core globally via `npm install -g @openfn/core` diff --git a/versioned_docs/version-legacy/getting-started/commcare-project-walkthrough.md b/versioned_docs/version-legacy/getting-started/commcare-project-walkthrough.md index c8c4e0d76aa..e74422d3d82 100644 --- a/versioned_docs/version-legacy/getting-started/commcare-project-walkthrough.md +++ b/versioned_docs/version-legacy/getting-started/commcare-project-walkthrough.md @@ -9,8 +9,8 @@ title: minute!) - You have checked out our glossary and have an understanding of basic OpenFn and API terminology. Check out the pages below to get started - - [OpenFn Concepts](/documentation/getting-started/terminology/) - - [A glossary for data integration](/documentation/getting-started/terminology/) + - [OpenFn Concepts](/documentation/get-started/terminology/) + - [A glossary for data integration](/documentation/get-started/terminology/) - You have a CommCare application with at least one form configured. This is your source system. - You have a PostgreSQL database configured. This is your destination system. @@ -110,7 +110,7 @@ In the credential `JSON Configuration`, add your credential as follows: :::tip -Check out [this](/documentation/getting-started/terminology/#inbox) docs page on +Check out [this](/documentation/get-started/terminology/#inbox) docs page on how to find your OpenFn inbox URL to fill in the configuration above. ::: @@ -213,7 +213,7 @@ there are 2:** configured the database [like this](https://docs.google.com/spreadsheets/d/1pi_oxImakhtaCCCIENkjTPZeuyWhpFEcNmH7hfvTBgo/edit?usp=sharing) to capture the CommCare form data. Check out the - [design quickstart](/documentation/design/design-quickstart#3-map-data-elements-to-be-exchanged) + [design quickstart](/documentation/design/design-overview#3-map-data-elements-to-be-exchanged) for how to create your own `mapping specification document` to map data elements to be exchanged. @@ -265,7 +265,7 @@ dataValue for source data fields in the OpenFn job studio. :::tip Check out the -[design quickstart](/documentation/design/design-quickstart#3-map-data-elements-to-be-exchanged) +[design quickstart](/documentation/design/design-overview#3-map-data-elements-to-be-exchanged) for how to create your own `mapping specification document` to map data elements to be exchanged. diff --git a/versioned_docs/version-legacy/getting-started/glossary.md b/versioned_docs/version-legacy/getting-started/glossary.md index d57aa6e204a..371857719ce 100644 --- a/versioned_docs/version-legacy/getting-started/glossary.md +++ b/versioned_docs/version-legacy/getting-started/glossary.md @@ -116,7 +116,7 @@ data to a destination system. ## Webhook -A [webhook](/documentation/source-apps#standard-webhook-configuration) (also called a web +A [webhook](/documentation/legacy/source-apps#standard-webhook-configuration) (also called a web callback or HTTP push API — thanks [SendGrid](https://sendgrid.com/blog/whats-webhook/)!) is a feature of an application that allows pushing. It's often configured to notify some diff --git a/versioned_docs/version-legacy/getting-started/implementation-checklist.md b/versioned_docs/version-legacy/getting-started/implementation-checklist.md index 88793ae2348..d328fbfb5cf 100644 --- a/versioned_docs/version-legacy/getting-started/implementation-checklist.md +++ b/versioned_docs/version-legacy/getting-started/implementation-checklist.md @@ -44,11 +44,11 @@ The XLS version of this template can be found [here](https://docs.google.com/spr ## (2) Discovery & Design - Functional Workflow Requirements - [ ] User stories documented to capture business value & desired outcomes - Learn more about user stories [here.](https://docs.openfn.org/documentation/design/design-quickstart#1-capture-requirements-as-user-stories) + Learn more about user stories [here.](https://docs.openfn.org/documentation/design/design-overview#1-capture-requirements-as-user-stories) - [ ] Workflow BPMN diagram capturing functional steps of the business process finalized - Learn more about diagrams & BPMN notation [here.](https://docs.openfn.org/documentation/design/design-quickstart#2-diagram-the-business-process) + Learn more about diagrams & BPMN notation [here.](https://docs.openfn.org/documentation/design/design-overview#2-diagram-the-business-process) - [ ] Request list of data elements from administrators of target systems - Read about mapping specs [here.](https://docs.openfn.org/documentation/design/design-quickstart#3-map-data-elements-to-be-exchanged). + Read about mapping specs [here.](https://docs.openfn.org/documentation/design/design-overview#3-map-data-elements-to-be-exchanged). - [ ] Data element mapping specifications finalized (functional/business-friendly version) - [ ] Client sign-offs on workflow diagram & mapping specs - [ ] Workflow assumptions documented (e.g., what human, manual steps does the workflow rely on; what are the unique identifiers) diff --git a/versioned_docs/version-legacy/getting-started/integration-toolkit.md b/versioned_docs/version-legacy/getting-started/integration-toolkit.md index e7828b605ea..560c4d4e970 100644 --- a/versioned_docs/version-legacy/getting-started/integration-toolkit.md +++ b/versioned_docs/version-legacy/getting-started/integration-toolkit.md @@ -90,7 +90,7 @@ Lightning is an upcoming addition to the Integration Toolkit. It is a _fully open source_ workflow automation platform designed for governments and NGOs who need a flexible solution to integrate and connect _any system_. -You can read all about it [here](/documentation/about-lightning)! +You can read all about it [here](/documentation#openfn-v2-lightning-)! ## Architecture for implementation diff --git a/versioned_docs/version-legacy/getting-started/security.md b/versioned_docs/version-legacy/getting-started/security.md index f21e28065c3..3e81f241675 100644 --- a/versioned_docs/version-legacy/getting-started/security.md +++ b/versioned_docs/version-legacy/getting-started/security.md @@ -103,7 +103,7 @@ Here are the key OpenFn templates and resources referenced in the Guidebook: - [Mapping Specification Template](https://docs.google.com/spreadsheets/d/1IqTIgOzyOztEevXbgY_4uE8Y8tiHXufZXx-IyJZase0/edit#gid=1822444315) - [Solution Architecture Diagram](https://lucid.app/lucidchart/1e997197-2d67-4393-8394-a532d83561b2/edit#?templateid=fb96ae05-e288-4d1f-b3fc-2cbf7641a7cc) -- [BPMN Diagram resources](/documentation/design/design-quickstart/#use-bpmn-for-standardized-documentation) +- [BPMN Diagram resources](/documentation/design/design-overview/#use-bpmn-for-standardized-documentation) - [Project Security Configuration & Go-Live Checklist](https://docs.google.com/document/d/1CbQkN7SqNmXeqt3nMTYP4ioQlTuwF2LbDkkFqhp0zsU/edit?usp=sharing) ### Communities of practice & other experts diff --git a/versioned_docs/version-legacy/getting-started/so-you-want-to-integrate.mdx b/versioned_docs/version-legacy/getting-started/so-you-want-to-integrate.mdx index 6bd50e4bbe5..bbfde574e2b 100644 --- a/versioned_docs/version-legacy/getting-started/so-you-want-to-integrate.mdx +++ b/versioned_docs/version-legacy/getting-started/so-you-want-to-integrate.mdx @@ -98,6 +98,6 @@ integration. Check out our docs on integration design to learn more about how we begin to answer these questions and more: - **Integration design:** - https://docs.openfn.org/documentation/design/design-quickstart/ + https://docs.openfn.org/documentation/design/design-overview/ - **Glossary for integration:** - https://docs.openfn.org/documentation/getting-started/glossary/ + https://docs.openfn.org/documentation/get-started/glossary/ diff --git a/versioned_docs/version-legacy/getting-started/terminology.md b/versioned_docs/version-legacy/getting-started/terminology.md index 4246c9ea78b..2e2e9445d39 100644 --- a/versioned_docs/version-legacy/getting-started/terminology.md +++ b/versioned_docs/version-legacy/getting-started/terminology.md @@ -23,14 +23,14 @@ With this in mind, let's check out the key terms. Please note that if you're looking for a glossary for generic terms used in data-integration (rather than this _OpenFn-specific_ stuff) head over to the -[Glossary for Integration](/documentation/getting-started/glossary) page in the +[Glossary for Integration](/documentation/get-started/glossary) page in the Design section. Otherwise, read on! ## Project A project is an administrative grouping in OpenFn. In -[OpenFn/microservice](/documentation/microservice/home/), it corresponds to a -[`project.yaml`](/documentation/portability#proposal-v2-latest) file. On the +[OpenFn/microservice](/documentation/deploy/portability/), it corresponds to a +[`project.yaml`](/documentation/deploy/portability#proposal-v2-latest) file. On the platform, it's got an owner, a billing plan, and a bunch of collaborators—different users that have been granted access to the project. In either case, a project contains jobs, triggers, credentials, and everything you @@ -44,7 +44,7 @@ Jobs are the **"what to do"** part of automation! ::: -OpenFn automation centers around [jobs](/documentation/build/jobs), which define +OpenFn automation centers around [jobs](/documentation/build/workflows), which define the specific series of operations (i.e., tasks) that OpenFn should perform. Jobs can be executed at certain times, when message arrive from outside systems, or when _other jobs_ succeed or fail. Think of jobs as a set of instructions you @@ -56,7 +56,7 @@ confirmation number when payment confirmation message is received etc.). :::note Jobs are Reusable Jobs are fully configurable and reusable. They can also be chained together to -create [multi-step automation](/documentation/jobs/multiple-operations) flows, +create [multi-step automation](/documentation/build/steps/multiple-operationss) flows, two-way syncs, and to keep data consistent between multiple applications (using multi-app Saga patterns). You can read more on two-way syncing below. @@ -72,7 +72,7 @@ adaptors at the moment, and anyone is free to build or enhance them. ### Operation -An [operation](/documentation/jobs/operations) is the sub-task inside a job. For +An [operation](/documentation/build/steps/operations) is the sub-task inside a job. For example, a job for loading data to DHIS2 might include 3 separate operations: 1. Create a new "program". @@ -116,7 +116,7 @@ and `headers` of the HTTP request that was made to your inbox. ### Inbox -Your project's [inbox](/documentation/build/inbox) contains all of the messages +Your project's [inbox](/documentation/legacy/build/inbox) contains all of the messages that have been sent to your project. Messages are stored payloads or data (e.g., an incoming SMS, a submitted CommCare form) that were sent via HTTP post to your inbox. diff --git a/versioned_docs/version-legacy/instant-openhie.md b/versioned_docs/version-legacy/instant-openhie.md index d883f026278..ed8533e31b6 100644 --- a/versioned_docs/version-legacy/instant-openhie.md +++ b/versioned_docs/version-legacy/instant-openhie.md @@ -6,7 +6,7 @@ title: Instant OpenHIE Please note that OpenFn/microservice and OpenFn/devtools are being deprecated and replaced by OpenFn/lightning, When Lighting is released, it may be used -within Instant OpenHIE (instead of microservice) as an OpenHIE-compliant workflow engine that can interface with the OpenHIE Interoperability Layer ([learn more](/documentation/about-lightning#standards-and-compliance-matter)). +within Instant OpenHIE (instead of microservice) as an OpenHIE-compliant workflow engine that can interface with the OpenHIE Interoperability Layer ([learn more](/documentation#openfn-v2-lightning-#standards-and-compliance-matter)). ::: @@ -291,10 +291,10 @@ These two methods are detailed below: [openhiestack]: https://openhim.readthedocs.io/en/latest/implementations/openhie.html [openhiearchitecture]: https://wiki.ohie.org/pages/viewpage.action?pageId=8454157 [openhim]: http://openhim.org/ -[jobs]: /documentation/build/jobs/ +[jobs]: /documentation/build/workflows/ [mediators]: http://openhim.org/mediator-library/ [demorepo]: https://github.com/OpenFn/instant-demo -[openfnmicroservice]: /documentation/microservice/home/ +[openfnmicroservice]: /documentation/deploy/portability/ [digitalsquare]: https://digitalsquare.org/ [fhir]: https://fhir.org/ [hapifhir]: https://hapifhir.io/ @@ -315,9 +315,9 @@ These two methods are detailed below: [testfile]: https://github.com/OpenFn/instant-demo/blob/main/test.js [instantdemo]: https://github.com/OpenFn/instant-demo [samplecred]: https://github.com/OpenFn/instant-demo/blob/main/openfn/docker/config/project.yaml#L165-L167 -[openfncli]: /documentation/devtools/home/#configure-an-openfn-project +[openfncli]: https://github.com/OpenFn/devtools/#configure-an-openfn-project [demoexpr]: https://github.com/OpenFn/instant-demo/tree/main/expressions -[jobexpr]: /documentation/build/jobs/#a-basic-expression +[jobexpr]: /documentation/build/workflows/#a-basic-expression [sampleyaml]: https://github.com/OpenFn/instant-demo/blob/main/openfn/docker/config/project.yaml [curl]: https://curl.se/ [studio]: /documentation/jobs/job-studio/ diff --git a/versioned_docs/version-legacy/intro/home.md b/versioned_docs/version-legacy/intro/home.md index e0b21b8da27..b51db2916e3 100644 --- a/versioned_docs/version-legacy/intro/home.md +++ b/versioned_docs/version-legacy/intro/home.md @@ -37,7 +37,7 @@ Some OpenFn use cases are: ## Who is it built by? -OpenFn products are built by the [Open Function Group](/documentation/about) and +OpenFn products are built by the [Open Function Group](/documentation) and a growing community of open-source contributors. ## Our products @@ -47,7 +47,7 @@ users the freedom to switch between any and all of the OpenFn products. All OpenFn products, other than the OpenFn iPaaS are part of the free and open-source -[**OpenFn Integration Toolkit**](/documentation/getting-started/integration-toolkit). +[**OpenFn Integration Toolkit**](/documentation#our-products). This Toolkit is a **Digital Public Good** (a "DPG") recognized in the [DPG Registry](https://digitalpublicgoods.net/registry/) and Digital Square's [Global Goods Guidebook](https://digitalsquare.org/resourcesrepository/global-goods-guidebook). diff --git a/versioned_docs/version-legacy/jobs/editing_locally.md b/versioned_docs/version-legacy/jobs/editing_locally.md index c09eab88858..ee8fe4daf14 100644 --- a/versioned_docs/version-legacy/jobs/editing_locally.md +++ b/versioned_docs/version-legacy/jobs/editing_locally.md @@ -6,7 +6,7 @@ To edit jobs, instead of using the OpenFn [Job Studio](/documentation/jobs/job-studio) you can also use your favorite text editor and make changes offline, committing and pushing to GitHub to deploy to your OpenFn using the -[version control feature](/documentation/manage/platform-mgmt/#github-version-control). +[version control feature](/documentation/legacy/manage/platform-mgmt/#github-version-control). First, make sure that version control is set up for your project and the job in question. When that's all done, follow the steps below: diff --git a/versioned_docs/version-legacy/jobs/job-design-intro.md b/versioned_docs/version-legacy/jobs/job-design-intro.md index b5a6966dd92..7a84ff64e70 100644 --- a/versioned_docs/version-legacy/jobs/job-design-intro.md +++ b/versioned_docs/version-legacy/jobs/job-design-intro.md @@ -10,7 +10,7 @@ other words, mapping data elements from one system to the other. Designing a job really just means clearly defining the “rules” for data element mapping. We'll walk through the main steps using Kobo Toolbox as an example -source system and a Postgres database as destination but check out the [integration design](/documentation/design/design-quickstart/) page for more details on data flow diagrams and mappings. +source system and a Postgres database as destination but check out the [integration design](/documentation/design/design-overview/) page for more details on data flow diagrams and mappings. Step 1: Map your data flows diff --git a/versioned_docs/version-legacy/jobs/job-studio.md b/versioned_docs/version-legacy/jobs/job-studio.md index ea2a11803f5..1c60e6fe635 100644 --- a/versioned_docs/version-legacy/jobs/job-studio.md +++ b/versioned_docs/version-legacy/jobs/job-studio.md @@ -3,8 +3,8 @@ title: The OpenFn Job Studio --- The OpenFn Job Studio allows you create and test jobs on the platform with easy -access to documentation of [adaptors](/documentation/build/jobs#adaptors), -matching [messages](/documentation/build/inbox) and real-time logs. +access to documentation of [adaptors](/documentation/build/workflows#adaptors), +matching [messages](/documentation/legacy/build/inbox) and real-time logs. ```mdx-code-block import ReactPlayer from 'react-player'; diff --git a/versioned_docs/version-legacy/manage/platform-mgmt.md b/versioned_docs/version-legacy/manage/platform-mgmt.md index 88ed8f59cf3..ce7756b4470 100644 --- a/versioned_docs/version-legacy/manage/platform-mgmt.md +++ b/versioned_docs/version-legacy/manage/platform-mgmt.md @@ -39,7 +39,7 @@ steps below: :::info Note that once a job is **switched on**, OpenFn will run it automatically, as -[configured](/documentation/build/jobs). If you do not want a job to be run +[configured](/documentation/build/workflows). If you do not want a job to be run automatically, by OpenFn, then turn it **off**. ::: @@ -198,14 +198,14 @@ The **four configuration steps** include giving the job a name, defining what [authentication](/documentation/build/credentials) details. The **expression editor** is the area where you write your -[job expression](/documentation/build/jobs/#composing-job-expressions). Fill-in +[job expression](/documentation/build/workflows/#composing-job-expressions). Fill-in all the details, and click on the **Save** icon in the top-right corner to save your job's configuration changes. #### Inspecting job's initial state This feature allows you to view the -[initial state](/documentation/jobs/state/#initial-state) of a selected job. +[initial state](/documentation/build/steps/state/#initial-state) of a selected job. Note that this feature is currently only available for [message-triggered jobs](/documentation/build/triggers#message-filter-triggers). @@ -219,7 +219,7 @@ as data path for the job's expression. #### Accessing inline adaptor documentation For a selected adaptor, OpenFn allows you to view documentation and code -examples for each [adaptor operation](/documentation/jobs/operations). +examples for each [adaptor operation](/documentation/build/steps/operations). To view adaptor documentation, click on the `documentation icon`(first icon) on the top-right corner of the `Expression Pane`. @@ -806,12 +806,12 @@ finished working on the first. #### Exporting Project Config - OpenFn allows you to run your project as a - [Microservice](/documentation/microservice/home/) . + [Microservice](/documentation/deploy/portability/) . - There are two options for exporting the project config used in OpenFn Microservice. Exporting as `project.yaml` will provide you with a `YAML` file that can be used to run this project with - [OpenFn/engine](/documentation/microservice/home/), - [OpenFn/microservice](/documentation/microservice/home/), or for use in + [OpenFn/engine](/documentation/deploy/portability/), + [OpenFn/microservice](/documentation/deploy/portability/), or for use in another OpenFn/platform space. - Exporting as `microservice.zip` will prepare a `ZIP` file with `openfn/microservice:latest` (from hub.docker.com) and a your `YAML` file diff --git a/versioned_docs/version-legacy/manage/troubleshooting-tips-on-platform.md b/versioned_docs/version-legacy/manage/troubleshooting-tips-on-platform.md index c9ba921ac21..e34a2fcf05e 100644 --- a/versioned_docs/version-legacy/manage/troubleshooting-tips-on-platform.md +++ b/versioned_docs/version-legacy/manage/troubleshooting-tips-on-platform.md @@ -12,7 +12,7 @@ Currently, this section is specific to **OpenFn/platform**. ## Runs One of the most helpful pages for troubleshooting on OpenFn platform is the -[Activity History](/documentation/getting-started/terminology/#activity-history). +[Activity History](/documentation/get-started/terminology/#activity-history). This pages provides a list of all of the runs executed in a project and always marks any failed runs red or yellow. Project administrators can troubleshoot errors by clicking into the run to review the run details. Keep reading for all @@ -23,7 +23,7 @@ troubleshooting! Every run will have an exit code. The exit code is a way for OpenFn to classify the run status and can help you troubleshoot errors. Learn more about OpenFn -exit codes and what each one means [here](/documentation/jobs/errors). +exit codes and what each one means [here](/documentation/monitor-history/troubleshooting). ### The time it took for the job to fail @@ -95,22 +95,22 @@ Leverage the various search functionalities in OpenFn to find the right messages and runs to support your troubleshooting. You can search in the Inbox, Activity History, and Search Console. -1. **[Inbox](/documentation/manage/platform-mgmt/#inbox)** - The inbox contains +1. **[Inbox](/documentation/legacy/manage/platform-mgmt/#inbox)** - The inbox contains all the messages that have been sent to your project. Search your project inbox for messages that contain a specific body text. You can also filter these messages by date, run status and trigger. You can even use filtering to see all the messages whose last run failed, so you can get to troubleshooting! Learn more about inbox filtering - [here](/documentation/manage/platform-mgmt/#inbox). + [here](/documentation/legacy/manage/platform-mgmt/#inbox). -2. **[Activity history](/documentation/getting-started/terminology/#activity-history)** - +2. **[Activity history](/documentation/get-started/terminology/#activity-history)** - As discussed above, the activity history records all runs for the current project. It has similar search and filtering capabilities as the inbox except it doesn't require valid JSON in the search box. Use the search in activity history instead of inbox when you want to search **_run logs_** instead of messages. -3. **[Search console](/documentation/manage/platform-mgmt/#search-console)** - +3. **[Search console](/documentation/legacy/manage/platform-mgmt/#search-console)** - The search console will search in both message bodies **_and_** run logs for any string is entered! @@ -123,7 +123,7 @@ leverage **bulk reprocessing** in the OpenFn inbox and activity history to reprocess all messages in the current filtered query. This means OpenFn will rerun all of those transactions in the order they were received. Learn more about bulk reprocessing -[here](/documentation/manage/platform-mgmt/#bulk-reprocess-messages). +[here](/documentation/legacy/manage/platform-mgmt/#bulk-reprocess-messages). Sometimes you'll have so many messages with failed runs that it will be virtually impossible to open each one and inspect the run logs. In this case, diff --git a/versioned_docs/version-legacy/openfn-roadmap.md b/versioned_docs/version-legacy/openfn-roadmap.md index c5a53b6f4e1..4144cb16091 100644 --- a/versioned_docs/version-legacy/openfn-roadmap.md +++ b/versioned_docs/version-legacy/openfn-roadmap.md @@ -20,7 +20,7 @@ product suite. This includes OpenFn/`Lightning`, `Adaptors`, and `Docs`. OpenFn/Lightning is the fully open-source workflow automation platform at the core of the OpenFn Digital Public Good (learn more about the product -[here](/documentation/about-lightning)). +[here](/documentation#openfn-v2-lightning-)). | **Feature** | **`Status`** | **Target Timeline** | **Related Links** | **Description** | | ---------------------------------------------------------------------- | ------------ | ------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | @@ -53,7 +53,7 @@ workflow engine, enable automated workflows that cut across digital systems. | **Feature** | **`Status`** | **Target Timeline** | **Related Links** | **Description** | | ------------------------------------------------------------------------------------------------- | ------------ | ------------------- | ------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| 1. Enhancements to [`FHIR`](http://www.hl7.org/fhir/) & [`OpenHIM`](http://openhim.org/) adaptors | Not Started | Q3 2023 | See existing adaptors for [FHIR](/adaptors/packages/fhir-docs) and [OpenHIM](/adaptors/packages/openhim-docs) | To rebuild the existing 2021 [OpenFn Instant-OpenHIE reference demo](/documentation/instant-openhie) to highlight the exchange of data between existing non-FHIR digital health tools and a HAPI FHIR server. (OpenFn Lightning is OpenHIE-compliant and can be used as a workflow engine for the OpenHIE Interoperability layer - [learn more here](/documentation/about-lightning#standards-and-compliance-matter).) We also want to demonstrate data exchange between existing non-FHIR digital health tools and key components of Google’s [Open Health Stack](https://developers.google.com/open-health-stack) and [Cloud Healthcare API](https://cloud.google.com/healthcare-api/docs/concepts/fhir) | +| 1. Enhancements to [`FHIR`](http://www.hl7.org/fhir/) & [`OpenHIM`](http://openhim.org/) adaptors | Not Started | Q3 2023 | See existing adaptors for [FHIR](/adaptors/packages/fhir-docs) and [OpenHIM](/adaptors/packages/openhim-docs) | To rebuild the existing 2021 [OpenFn Instant-OpenHIE reference demo](/documentation/get-started/standards#openhie-standard-architecture) to highlight the exchange of data between existing non-FHIR digital health tools and a HAPI FHIR server. (OpenFn Lightning is OpenHIE-compliant and can be used as a workflow engine for the OpenHIE Interoperability layer - [learn more here](/documentation#openfn-v2-lightning-#standards-and-compliance-matter).) We also want to demonstrate data exchange between existing non-FHIR digital health tools and key components of Google’s [Open Health Stack](https://developers.google.com/open-health-stack) and [Cloud Healthcare API](https://cloud.google.com/healthcare-api/docs/concepts/fhir) | | 2. Add "magic" functions to existing, in-demand adaptors | Not started | Q3 2023 | [Issue 243](https://github.com/OpenFn/adaptors/issues/243) | Add functions, dynamic lists, and shortcuts to fast-track workflow configuration for key adaptors including HTTP, [DHIS2](https://dhis2.org/), [CommCare](https://www.dimagi.com/commcare/), & [OpenMRS](https://openmrs.org/) | | 3. New [`OpenMRS`](https://openmrs.org/) adaptor version | Not started | Q3 2023 | [See existing adaptor docs](/adaptors/packages/openmrs-readme) | To ensure compliance with OpenMRS v3 | | 4. Enhancements to the [`OCL`](https://openconceptlab.org/) adaptor | Not started | Q3 2023 | [See existing adaptor docs](/adaptors/packages/ocl-readme) | To ensure that mappings stored in OCLs can be more easily access and processed as inputs in OpenFn/Lightning workflows | @@ -62,7 +62,7 @@ workflow engine, enable automated workflows that cut across digital systems. | **Feature** | **`Status`** | **Target Timeline** | **Related Links** | **Description** | | ----------------------------------------------------------- | ------------ | ------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| 1. OpenFn and the [OpenHIE](https://ohie.org/) architecture | Planned | Q2 2023 | [See current docs](/documentation/about-lightning#standards-and-compliance-matter) | New page dedicated to how OpenHIE aligns with OpenHIE architecture; expansion of the existing small section on standards | +| 1. OpenFn and the [OpenHIE](https://ohie.org/) architecture | Planned | Q2 2023 | [See current docs](/documentation#openfn-v2-lightning-#standards-and-compliance-matter) | New page dedicated to how OpenHIE aligns with OpenHIE architecture; expansion of the existing small section on standards | | 2. New Lightning User Guidance | Not started | Q3 2023 | To be hosted on docs.openfn.org | New documentation, videos, and other user guidance on how to use OpenFn/Lightning and how to migrate existing OpenFn/platform projects to Lightning (the new OpenFn "v2") | | 3. Template [FHIR](http://www.hl7.org/fhir/) Workflows | Planned | Q3 2023 | To be hosted on demo.openfn.org | OpenFn can already help achieve FHIR compliance, but we will build and document reference/template workflows to demonstrate how OpenFn/Lightning can automate data exchange, registration, and/or reporting workflows between non-FHIR data systems and FHIR APIs. | | 4. Template Alerting Workflows | Not started | Q4 2023 | [See OpenHIE docs](https://guides.ohie.org/arch-spec/introduction/alerting-sending-reminders-or-information); to be hosted on demo.openfn.org | To demonstrate how OpenFn can facilitate one-way communication to a client or provider listed in the HIE (from the OpenHIE standard spec) | diff --git a/versioned_docs/version-legacy/portability-versions.md b/versioned_docs/version-legacy/portability-versions.md index f824370d7ba..aef89fad1fb 100644 --- a/versioned_docs/version-legacy/portability-versions.md +++ b/versioned_docs/version-legacy/portability-versions.md @@ -10,7 +10,7 @@ be used to import or export projects between OpenFn/platform and OpenFn/engine. The portability specification v4 defines how entire projects (groups of workflows with their associated triggers, credentials and jobs) can be represented as code. This specification has been written for -[Lightning](/documentation/getting-started/integration-toolkit/#lightning-coming-soon), +[Lightning](/documentation#our-products/#lightning-coming-soon), the fully open source webb app which extends the OpenFn DPG. It aims to (a) improve developer experience, allowing them to build and test workflows locally; (b) enable version control and an audit trail of project changes; and (c) enable From a1bed8692cdc941edd584ee8b19059e254966497 Mon Sep 17 00:00:00 2001 From: aleksa-krolls Date: Mon, 12 Feb 2024 18:07:27 +0200 Subject: [PATCH 3/8] reverse link edits where legacy added --- docs/get-started/glossary.md | 2 +- .../troubleshooting-tips-on-platform.md | 214 ------------------ docs/monitor-history/troubleshooting.md | 6 +- .../getting-started/glossary.md | 2 +- .../getting-started/terminology.md | 2 +- .../version-legacy/jobs/editing_locally.md | 2 +- .../version-legacy/jobs/job-studio.md | 2 +- .../troubleshooting-tips-on-platform.md | 8 +- 8 files changed, 13 insertions(+), 225 deletions(-) delete mode 100644 docs/manage-projects/troubleshooting-tips-on-platform.md diff --git a/docs/get-started/glossary.md b/docs/get-started/glossary.md index 87b1dc45b9d..4a4dcd22f44 100644 --- a/docs/get-started/glossary.md +++ b/docs/get-started/glossary.md @@ -133,7 +133,7 @@ data to a destination system. ## Webhook -A [webhook](/documentation/legacy/source-apps#standard-webhook-configuration) (also +A [webhook](/documentation/build/triggers#webhook-event-triggers) (also called a web callback or HTTP push API — thanks [SendGrid](https://sendgrid.com/blog/whats-webhook/)!) is a feature of an application that allows pushing. It's often configured to notify some diff --git a/docs/manage-projects/troubleshooting-tips-on-platform.md b/docs/manage-projects/troubleshooting-tips-on-platform.md deleted file mode 100644 index e34a2fcf05e..00000000000 --- a/docs/manage-projects/troubleshooting-tips-on-platform.md +++ /dev/null @@ -1,214 +0,0 @@ ---- -title: Troubleshooting Platform -sidebar_label: Troubleshooting ---- - -:::important - -Currently, this section is specific to **OpenFn/platform**. - -::: - -## Runs - -One of the most helpful pages for troubleshooting on OpenFn platform is the -[Activity History](/documentation/get-started/terminology/#activity-history). -This pages provides a list of all of the runs executed in a project and always -marks any failed runs red or yellow. Project administrators can troubleshoot -errors by clicking into the run to review the run details. Keep reading for all -the important parts of a run and how to leverage them during your -troubleshooting! - -### Exit codes - -Every run will have an exit code. The exit code is a way for OpenFn to classify -the run status and can help you troubleshoot errors. Learn more about OpenFn -exit codes and what each one means [here](/documentation/monitor-history/troubleshooting). - -### The time it took for the job to fail - -The run will also record how long it took before the job failed. This -information helps users understand if the job is taking longer than it should -and is especially helpful with errors that involve timeouts. You can use the run -to determine at which operation the job is timing out and determine if the job -performance can be optimized. - -### Run logs - -As jobs are developed it is important to log details which will make testing and -troubleshooting much easier in the future. Keep reading for the two most -important parts of a run log! - -#### Mappings - -The logs should be written so that you can see exactly what was mapped between -the source system and the destination system. In cases where data received from -the source system is _not_ being posted to the OpenFn inbox (often for security -reasons), it can even be helpful to log the data that was received. In summary, -the log can have a **"Data received from source system"** section and a **"Data -to be uploaded to destination system"** section. - -These logs can help admins verify that the source data and the data being -uploaded to the destination system is correct. For example, seeing in the logs -that that a unique identifier is being mapped to `undefined` in the destination -system can help you understand this Salesforce error message: - -`METHOD_NOT_ALLOWED: HTTP Method 'PATCH' not allowed. Allowed are GET,HEAD,POST at HttpApi.getError`. - -#### Error messages - -The run log should also tell us if an error has been thrown, and depending on -the destination system, what the error message is. Sometimes the error message -is very specific like: - -`NOT_FOUND: Provided external ID field does not exist or is not accessible` - -This error from Salesforce usually indicates that `External ID` has not been -checked in the field settings in Salesforce. - -Other error messages are not as clear and can take some time to debug: - -`TypeError [Error]: Cannot read property 'split' of undefined` - -**`TypeErrors`** usually indicate that the job received a part of the message -that it wasn't expecting, or there is a syntax error in your job code. It means -that the job needs to be updated to know how to handle the message. In this -case, the job received an old version of the Commcare form which was missing a -field which the job called the `split` function on. You can determine this by -reviewing the job for which fields the split function is being called on and -checking that they are all present in the message. - -The more you test and troubleshoot with a particular system, the more familiar -with it's error messages you become. - -:::tip - -OpenFn has outlined several of the more common error messages specific to some -of the systems that we have integrated in the past. Explore these systems and -their error messages [here](/adaptors#connect-anything). - -::: - -## Leveraging search and filtering in OpenFn - -Leverage the various search functionalities in OpenFn to find the right messages -and runs to support your troubleshooting. You can search in the Inbox, Activity -History, and Search Console. - -1. **[Inbox](/documentation/legacy/manage/platform-mgmt/#inbox)** - The inbox contains - all the messages that have been sent to your project. Search your project - inbox for messages that contain a specific body text. You can also filter - these messages by date, run status and trigger. You can even use filtering to - see all the messages whose last run failed, so you can get to - troubleshooting! Learn more about inbox filtering - [here](/documentation/legacy/manage/platform-mgmt/#inbox). - -2. **[Activity history](/documentation/get-started/terminology/#activity-history)** - - As discussed above, the activity history records all runs for the current - project. It has similar search and filtering capabilities as the inbox except - it doesn't require valid JSON in the search box. Use the search in activity - history instead of inbox when you want to search **_run logs_** instead of - messages. - -3. **[Search console](/documentation/legacy/manage/platform-mgmt/#search-console)** - - The search console will search in both message bodies **_and_** run logs for - any string is entered! - -## Bulk reprocessing - -Sometimes you'll see several messages in the inbox whose last run failed because -of the same error. Once you have resolved the error, you can test it by -rerunning the transaction for one failed run. If this passes, you can then -leverage **bulk reprocessing** in the OpenFn inbox and activity history to -reprocess all messages in the current filtered query. This means OpenFn will -rerun all of those transactions in the order they were received. Learn more -about bulk reprocessing -[here](/documentation/legacy/manage/platform-mgmt/#bulk-reprocess-messages). - -Sometimes you'll have so many messages with failed runs that it will be -virtually impossible to open each one and inspect the run logs. In this case, -you can resolve the errors and bulk reprocess as you go, each time reducing the -number of failures in the inbox and generating a short list of the remaining -errors. - -## Other tips - -- **Posting messages to the inbox** - You can post messages directly to the - OpenFn inbox by clicking the **plus** icon on the bottom left of the inbox. - This feature can come in handy when you have lengthy messages which include - several rows of data. You simply copy and paste one row of data from the - original message to a new message and post it to the inbox. This allows you to - troubleshoot individual rows of data. -- **Editing messages** - Messages in the inbox can be edited by clicking the - pencil icon in the message. This is a quick way to update and test any mapping - fixes with data that is already in the inbox. Once you verify that the run for - the updated message passes, you can make the appropriate updates to the source - sytem and post the correct data to the inbox moving forward. -- **Organizing error messages** - When working with various different jobs and - error messages, it is helpful to organize all errors in a spreadsheet which - links to the last run, error, and status. - -## Sign up for email alerts - -You can turn on notifications to receive email alerts when a job fails. When you -receive an error email, you can click “inspect & take action” to be taken to the -failed run and being troubleshooting! - -## More - -> What happens if my survey data from ODK needs to link to existing records in -> my Salesforce system but a respondent enters or selects an invalid -> `external ID`? - -Great question, and don't worry, it happens all the time. Assuming you've -already taken all possible measures to either pre-load external IDs in your ODK -form or use more human-proof IDs (like barcodes and fingerprints) here's the -flow of work: - -1. Read the email, and inspect the reason for failure. - -2. 99% of failed runs on OpenFn are due to `value mismatches`. The _collected_ - `id` in ODK doesn't match the _expected_ `id` in Salesforce. You must now - chose to either: - - A. Edit the source `id` in your `receipt` & retry the attempt. - - B. Edit the related `id` in your destination system & retry the attempt. - - C. Ignore the attempt—this source data will never reach your destination - system. (There have been reports of ODK Aggregate's JSON publisher sending - duplicate values. If that happens and your run fails due to "duplicate - values" on a particular unique field you can safely ignore the run in - OpenFn.) - -Editing data in your destination system can be done through that system's -interface. Many tools that act as `sources` (like ODK) do not allow for easy -editing and re-submission of data. You can use OpenFn to edit the source data -before retrying the attempt. - -### Common Error Messages - -The most common error messages with English explanations are: - -```sh -DUPLICATE_VALUE: duplicate value found: ODK_uuid__c duplicates value on record with id: a0524000005wNw0 -The insert is blocked because you are attempting to create a new record with a -unique field with the same value as an existing record. -``` - -```sh -Required value missing -``` - -```sh -ExternalId not found -``` - -```sh -{ INVALID_FIELD_FOR_INSERT_UPDATE: Unable to create/update fields: Contact__c. -Please check the security settings of this field and verify that it is -read/write for your profile or permission set. } -``` - -This last one may arise if a master-detail relationship in Salesforce is not set -as reparentable and the user attempts to run an upsert. diff --git a/docs/monitor-history/troubleshooting.md b/docs/monitor-history/troubleshooting.md index 0a3495ebea9..7c6b27214f1 100644 --- a/docs/monitor-history/troubleshooting.md +++ b/docs/monitor-history/troubleshooting.md @@ -3,7 +3,7 @@ title: Troubleshooting sidebar_label: Troubleshooting --- - +This page provides troubleshooting tips for *OpenFn v2 platform* users. ## Runs @@ -81,7 +81,9 @@ their error messages [here](/adaptors#connect-anything). ## Leveraging search and filtering in OpenFn -Leverage the various search functionalities in OpenFn to find the right runs to support your troubleshooting. You can search on the History page across OpenFn IDs, Inputs, and/or Logs. Check out this [video](https://youtu.be/XIUykmLCxwQ?si=hquc8rPTJrAZkbbD) for how to use Search. +Leverage the various search functionalities in OpenFn to find the right runs to support your troubleshooting. You can search on the History page across OpenFn IDs, Inputs, and/or Logs. + +Check out this [video](https://youtu.be/XIUykmLCxwQ?si=hquc8rPTJrAZkbbD) for how to use Search. diff --git a/versioned_docs/version-legacy/getting-started/glossary.md b/versioned_docs/version-legacy/getting-started/glossary.md index 371857719ce..d57aa6e204a 100644 --- a/versioned_docs/version-legacy/getting-started/glossary.md +++ b/versioned_docs/version-legacy/getting-started/glossary.md @@ -116,7 +116,7 @@ data to a destination system. ## Webhook -A [webhook](/documentation/legacy/source-apps#standard-webhook-configuration) (also called a web +A [webhook](/documentation/source-apps#standard-webhook-configuration) (also called a web callback or HTTP push API — thanks [SendGrid](https://sendgrid.com/blog/whats-webhook/)!) is a feature of an application that allows pushing. It's often configured to notify some diff --git a/versioned_docs/version-legacy/getting-started/terminology.md b/versioned_docs/version-legacy/getting-started/terminology.md index 2e2e9445d39..ec4059a8f13 100644 --- a/versioned_docs/version-legacy/getting-started/terminology.md +++ b/versioned_docs/version-legacy/getting-started/terminology.md @@ -116,7 +116,7 @@ and `headers` of the HTTP request that was made to your inbox. ### Inbox -Your project's [inbox](/documentation/legacy/build/inbox) contains all of the messages +Your project's [inbox](/documentation/build/inbox) contains all of the messages that have been sent to your project. Messages are stored payloads or data (e.g., an incoming SMS, a submitted CommCare form) that were sent via HTTP post to your inbox. diff --git a/versioned_docs/version-legacy/jobs/editing_locally.md b/versioned_docs/version-legacy/jobs/editing_locally.md index ee8fe4daf14..c09eab88858 100644 --- a/versioned_docs/version-legacy/jobs/editing_locally.md +++ b/versioned_docs/version-legacy/jobs/editing_locally.md @@ -6,7 +6,7 @@ To edit jobs, instead of using the OpenFn [Job Studio](/documentation/jobs/job-studio) you can also use your favorite text editor and make changes offline, committing and pushing to GitHub to deploy to your OpenFn using the -[version control feature](/documentation/legacy/manage/platform-mgmt/#github-version-control). +[version control feature](/documentation/manage/platform-mgmt/#github-version-control). First, make sure that version control is set up for your project and the job in question. When that's all done, follow the steps below: diff --git a/versioned_docs/version-legacy/jobs/job-studio.md b/versioned_docs/version-legacy/jobs/job-studio.md index 1c60e6fe635..54a7a98a4f0 100644 --- a/versioned_docs/version-legacy/jobs/job-studio.md +++ b/versioned_docs/version-legacy/jobs/job-studio.md @@ -4,7 +4,7 @@ title: The OpenFn Job Studio The OpenFn Job Studio allows you create and test jobs on the platform with easy access to documentation of [adaptors](/documentation/build/workflows#adaptors), -matching [messages](/documentation/legacy/build/inbox) and real-time logs. +matching [messages](/documentation/build/inbox) and real-time logs. ```mdx-code-block import ReactPlayer from 'react-player'; diff --git a/versioned_docs/version-legacy/manage/troubleshooting-tips-on-platform.md b/versioned_docs/version-legacy/manage/troubleshooting-tips-on-platform.md index e34a2fcf05e..cce621c6afd 100644 --- a/versioned_docs/version-legacy/manage/troubleshooting-tips-on-platform.md +++ b/versioned_docs/version-legacy/manage/troubleshooting-tips-on-platform.md @@ -95,13 +95,13 @@ Leverage the various search functionalities in OpenFn to find the right messages and runs to support your troubleshooting. You can search in the Inbox, Activity History, and Search Console. -1. **[Inbox](/documentation/legacy/manage/platform-mgmt/#inbox)** - The inbox contains +1. **[Inbox](/documentation/manage/platform-mgmt/#inbox)** - The inbox contains all the messages that have been sent to your project. Search your project inbox for messages that contain a specific body text. You can also filter these messages by date, run status and trigger. You can even use filtering to see all the messages whose last run failed, so you can get to troubleshooting! Learn more about inbox filtering - [here](/documentation/legacy/manage/platform-mgmt/#inbox). + [here](/documentation/manage/platform-mgmt/#inbox). 2. **[Activity history](/documentation/get-started/terminology/#activity-history)** - As discussed above, the activity history records all runs for the current @@ -110,7 +110,7 @@ History, and Search Console. history instead of inbox when you want to search **_run logs_** instead of messages. -3. **[Search console](/documentation/legacy/manage/platform-mgmt/#search-console)** - +3. **[Search console](/documentation/manage/platform-mgmt/#search-console)** - The search console will search in both message bodies **_and_** run logs for any string is entered! @@ -123,7 +123,7 @@ leverage **bulk reprocessing** in the OpenFn inbox and activity history to reprocess all messages in the current filtered query. This means OpenFn will rerun all of those transactions in the order they were received. Learn more about bulk reprocessing -[here](/documentation/legacy/manage/platform-mgmt/#bulk-reprocess-messages). +[here](/documentation/manage/platform-mgmt/#bulk-reprocess-messages). Sometimes you'll have so many messages with failed runs that it will be virtually impossible to open each one and inspect the run logs. In this case, From 0627b16656f5d9eb824d64268622b309d79b78e7 Mon Sep 17 00:00:00 2001 From: aleksa-krolls Date: Mon, 12 Feb 2024 18:35:00 +0200 Subject: [PATCH 4/8] fixing links on legacy docs to preserve old link paths --- .../version-legacy/build/example-build.md | 2 +- versioned_docs/version-legacy/build/inbox.md | 2 +- versioned_docs/version-legacy/build/jobs.md | 2 +- .../build/lightning-quick-start.md | 2 +- .../version-legacy/design/design-quickstart.md | 4 ++-- .../commcare-project-walkthrough.md | 10 +++++----- .../getting-started/implementation-checklist.md | 6 +++--- .../getting-started/integration-toolkit.md | 9 ++++++++- .../version-legacy/getting-started/security.md | 2 +- .../getting-started/so-you-want-to-integrate.mdx | 6 ++---- .../getting-started/terminology.md | 12 ++++++------ versioned_docs/version-legacy/instant-openhie.md | 10 +++++----- versioned_docs/version-legacy/intro/home.md | 4 ++-- .../version-legacy/jobs/job-design-intro.md | 2 +- versioned_docs/version-legacy/jobs/job-studio.md | 2 +- .../version-legacy/manage/platform-mgmt.md | 16 ++++++++-------- .../manage/troubleshooting-tips-on-platform.md | 6 +++--- versioned_docs/version-legacy/openfn-roadmap.md | 6 +++--- .../version-legacy/portability-versions.md | 2 +- 19 files changed, 55 insertions(+), 50 deletions(-) diff --git a/versioned_docs/version-legacy/build/example-build.md b/versioned_docs/version-legacy/build/example-build.md index fbf659a370d..68781b82cf6 100644 --- a/versioned_docs/version-legacy/build/example-build.md +++ b/versioned_docs/version-legacy/build/example-build.md @@ -139,7 +139,7 @@ snippet comes into your inbox. Save your trigger. You should see a confirmation message “Found x matching messages”. To see the data from your last message inside the -[initial state](/documentation/build/steps/state/#initial-state), drag the +[initial state](/documentation/jobs/state), drag the **Expression** panel to the right. ![trigger message](/img/4.3_trigger_message.png 'View a matching trigger message in initial state') diff --git a/versioned_docs/version-legacy/build/inbox.md b/versioned_docs/version-legacy/build/inbox.md index b265bb90c7b..389ae51b8d8 100644 --- a/versioned_docs/version-legacy/build/inbox.md +++ b/versioned_docs/version-legacy/build/inbox.md @@ -58,7 +58,7 @@ operations in step 4 completed successfully (what do you count as a success with these various custom actions, by the way?) you should consider implementing a SAGA pattern, whereby after all this processing is complete you trigger another request back to the initial system reporting on the downstream tasks. This can -be done in OpenFn with [Flow Triggers](/documentation/build/steps/multiple-operationss). +be done in OpenFn with [Flow Triggers](/documentation/jobs/multiple-operations). ## Synchronous vs. Asynchronous Processing diff --git a/versioned_docs/version-legacy/build/jobs.md b/versioned_docs/version-legacy/build/jobs.md index eb2eaef7628..6ae92379689 100644 --- a/versioned_docs/version-legacy/build/jobs.md +++ b/versioned_docs/version-legacy/build/jobs.md @@ -207,7 +207,7 @@ language-packs. #### each() -Read more about each here: [The each(...) operation](/documentation/build/steps/each) +Read more about each here: [The each(...) operation](/documentation/jobs/each) ```js each( diff --git a/versioned_docs/version-legacy/build/lightning-quick-start.md b/versioned_docs/version-legacy/build/lightning-quick-start.md index 252da254ffe..c2b70e769e8 100644 --- a/versioned_docs/version-legacy/build/lightning-quick-start.md +++ b/versioned_docs/version-legacy/build/lightning-quick-start.md @@ -128,7 +128,7 @@ state (which contains your input) to use. When you need to use data that comes from your webhook trigger (data sent from your external system), cron trigger, or a previous job you can find it in -`state`. Learn more [here](https://docs.openfn.org/documentation/build/steps/state/). +`state`. Learn more [here](/documentation/jobs/state/). ::: diff --git a/versioned_docs/version-legacy/design/design-quickstart.md b/versioned_docs/version-legacy/design/design-quickstart.md index 7c4184200bd..21791e27d2d 100644 --- a/versioned_docs/version-legacy/design/design-quickstart.md +++ b/versioned_docs/version-legacy/design/design-quickstart.md @@ -69,7 +69,7 @@ information will be exchanged? With _whom_ (between which systems or users)? _When_ will the information be exchanged? And what are the human or automation steps that should facilitate and trigger this exchange? These business process questions are discussed in more detail on the -[So, what is an integration?](/documentation/tutorials/tutorial/) +[So, what is an integration?](/documentation/getting-started/so-you-want-to-integrate/) page. :::tip @@ -189,5 +189,5 @@ solution, as well as memorialize the business decisions and agreements made by implementing partners. Share this documentation with any technical implementation team, or check out -the [Build](/documentation/build/workflows) documentation section to learn how to +the [Build](/documentation/build/jobs) documentation section to learn how to implement these design specifications using OpenFn. diff --git a/versioned_docs/version-legacy/getting-started/commcare-project-walkthrough.md b/versioned_docs/version-legacy/getting-started/commcare-project-walkthrough.md index e74422d3d82..75708d39213 100644 --- a/versioned_docs/version-legacy/getting-started/commcare-project-walkthrough.md +++ b/versioned_docs/version-legacy/getting-started/commcare-project-walkthrough.md @@ -9,8 +9,8 @@ title: minute!) - You have checked out our glossary and have an understanding of basic OpenFn and API terminology. Check out the pages below to get started - - [OpenFn Concepts](/documentation/get-started/terminology/) - - [A glossary for data integration](/documentation/get-started/terminology/) + - [OpenFn Concepts](/documentation/getting-started/terminology/) + - [A glossary for data integration](/documentation/getting-started/glossary/) - You have a CommCare application with at least one form configured. This is your source system. - You have a PostgreSQL database configured. This is your destination system. @@ -110,7 +110,7 @@ In the credential `JSON Configuration`, add your credential as follows: :::tip -Check out [this](/documentation/get-started/terminology/#inbox) docs page on +Check out [this](/documentation/getting-started/terminology/#inbox) docs page on how to find your OpenFn inbox URL to fill in the configuration above. ::: @@ -213,7 +213,7 @@ there are 2:** configured the database [like this](https://docs.google.com/spreadsheets/d/1pi_oxImakhtaCCCIENkjTPZeuyWhpFEcNmH7hfvTBgo/edit?usp=sharing) to capture the CommCare form data. Check out the - [design quickstart](/documentation/design/design-overview#3-map-data-elements-to-be-exchanged) + [design quickstart](/documentation/design/design-quickstart#3-map-data-elements-to-be-exchanged) for how to create your own `mapping specification document` to map data elements to be exchanged. @@ -265,7 +265,7 @@ dataValue for source data fields in the OpenFn job studio. :::tip Check out the -[design quickstart](/documentation/design/design-overview#3-map-data-elements-to-be-exchanged) +[design quickstart](/documentation/design/design-quickstart#3-map-data-elements-to-be-exchanged) for how to create your own `mapping specification document` to map data elements to be exchanged. diff --git a/versioned_docs/version-legacy/getting-started/implementation-checklist.md b/versioned_docs/version-legacy/getting-started/implementation-checklist.md index d328fbfb5cf..88793ae2348 100644 --- a/versioned_docs/version-legacy/getting-started/implementation-checklist.md +++ b/versioned_docs/version-legacy/getting-started/implementation-checklist.md @@ -44,11 +44,11 @@ The XLS version of this template can be found [here](https://docs.google.com/spr ## (2) Discovery & Design - Functional Workflow Requirements - [ ] User stories documented to capture business value & desired outcomes - Learn more about user stories [here.](https://docs.openfn.org/documentation/design/design-overview#1-capture-requirements-as-user-stories) + Learn more about user stories [here.](https://docs.openfn.org/documentation/design/design-quickstart#1-capture-requirements-as-user-stories) - [ ] Workflow BPMN diagram capturing functional steps of the business process finalized - Learn more about diagrams & BPMN notation [here.](https://docs.openfn.org/documentation/design/design-overview#2-diagram-the-business-process) + Learn more about diagrams & BPMN notation [here.](https://docs.openfn.org/documentation/design/design-quickstart#2-diagram-the-business-process) - [ ] Request list of data elements from administrators of target systems - Read about mapping specs [here.](https://docs.openfn.org/documentation/design/design-overview#3-map-data-elements-to-be-exchanged). + Read about mapping specs [here.](https://docs.openfn.org/documentation/design/design-quickstart#3-map-data-elements-to-be-exchanged). - [ ] Data element mapping specifications finalized (functional/business-friendly version) - [ ] Client sign-offs on workflow diagram & mapping specs - [ ] Workflow assumptions documented (e.g., what human, manual steps does the workflow rely on; what are the unique identifiers) diff --git a/versioned_docs/version-legacy/getting-started/integration-toolkit.md b/versioned_docs/version-legacy/getting-started/integration-toolkit.md index 560c4d4e970..95d2124d72f 100644 --- a/versioned_docs/version-legacy/getting-started/integration-toolkit.md +++ b/versioned_docs/version-legacy/getting-started/integration-toolkit.md @@ -2,6 +2,13 @@ title: The Integration Toolkit --- +:::warning + +This page is from the v1 legacy docs. Visit the "v2" docs to see an updated +overview on the OpenFn Integration Toolkit and its products. + +::: + OpenFn's free and open-source Integration Toolkit gives governments and NGOs around the world more flexibility and freedom to chose how they achieve success in integration and interoperability projects. The Toolkit is both a recognized @@ -90,7 +97,7 @@ Lightning is an upcoming addition to the Integration Toolkit. It is a _fully open source_ workflow automation platform designed for governments and NGOs who need a flexible solution to integrate and connect _any system_. -You can read all about it [here](/documentation#openfn-v2-lightning-)! +You can read all about it [here](/documentation/about-lightning)! ## Architecture for implementation diff --git a/versioned_docs/version-legacy/getting-started/security.md b/versioned_docs/version-legacy/getting-started/security.md index 3e81f241675..f21e28065c3 100644 --- a/versioned_docs/version-legacy/getting-started/security.md +++ b/versioned_docs/version-legacy/getting-started/security.md @@ -103,7 +103,7 @@ Here are the key OpenFn templates and resources referenced in the Guidebook: - [Mapping Specification Template](https://docs.google.com/spreadsheets/d/1IqTIgOzyOztEevXbgY_4uE8Y8tiHXufZXx-IyJZase0/edit#gid=1822444315) - [Solution Architecture Diagram](https://lucid.app/lucidchart/1e997197-2d67-4393-8394-a532d83561b2/edit#?templateid=fb96ae05-e288-4d1f-b3fc-2cbf7641a7cc) -- [BPMN Diagram resources](/documentation/design/design-overview/#use-bpmn-for-standardized-documentation) +- [BPMN Diagram resources](/documentation/design/design-quickstart/#use-bpmn-for-standardized-documentation) - [Project Security Configuration & Go-Live Checklist](https://docs.google.com/document/d/1CbQkN7SqNmXeqt3nMTYP4ioQlTuwF2LbDkkFqhp0zsU/edit?usp=sharing) ### Communities of practice & other experts diff --git a/versioned_docs/version-legacy/getting-started/so-you-want-to-integrate.mdx b/versioned_docs/version-legacy/getting-started/so-you-want-to-integrate.mdx index bbfde574e2b..f87022f73d6 100644 --- a/versioned_docs/version-legacy/getting-started/so-you-want-to-integrate.mdx +++ b/versioned_docs/version-legacy/getting-started/so-you-want-to-integrate.mdx @@ -97,7 +97,5 @@ These are all very important questions to consider when designing an integration. Check out our docs on integration design to learn more about how we begin to answer these questions and more: -- **Integration design:** - https://docs.openfn.org/documentation/design/design-overview/ -- **Glossary for integration:** - https://docs.openfn.org/documentation/get-started/glossary/ +- [**Integration design:**](/documentation/design/design-quickstart/) +- [**Glossary for integration:**](/documentation/getting-started/glossary/) diff --git a/versioned_docs/version-legacy/getting-started/terminology.md b/versioned_docs/version-legacy/getting-started/terminology.md index ec4059a8f13..059ea2f8a74 100644 --- a/versioned_docs/version-legacy/getting-started/terminology.md +++ b/versioned_docs/version-legacy/getting-started/terminology.md @@ -23,14 +23,14 @@ With this in mind, let's check out the key terms. Please note that if you're looking for a glossary for generic terms used in data-integration (rather than this _OpenFn-specific_ stuff) head over to the -[Glossary for Integration](/documentation/get-started/glossary) page in the +[Glossary for Integration](/documentation/getting-started/glossary) page in the Design section. Otherwise, read on! ## Project A project is an administrative grouping in OpenFn. In -[OpenFn/microservice](/documentation/deploy/portability/), it corresponds to a -[`project.yaml`](/documentation/deploy/portability#proposal-v2-latest) file. On the +[OpenFn/microservice](https://github.com/OpenFn/microservice), it corresponds to a +[`project.yaml`](/documentation/portability#proposal-v2-latest) file. On the platform, it's got an owner, a billing plan, and a bunch of collaborators—different users that have been granted access to the project. In either case, a project contains jobs, triggers, credentials, and everything you @@ -44,7 +44,7 @@ Jobs are the **"what to do"** part of automation! ::: -OpenFn automation centers around [jobs](/documentation/build/workflows), which define +OpenFn automation centers around [jobs](/documentation/build/jobs), which define the specific series of operations (i.e., tasks) that OpenFn should perform. Jobs can be executed at certain times, when message arrive from outside systems, or when _other jobs_ succeed or fail. Think of jobs as a set of instructions you @@ -56,7 +56,7 @@ confirmation number when payment confirmation message is received etc.). :::note Jobs are Reusable Jobs are fully configurable and reusable. They can also be chained together to -create [multi-step automation](/documentation/build/steps/multiple-operationss) flows, +create [multi-step automation](/documentation/jobs/multiple-operations) flows, two-way syncs, and to keep data consistent between multiple applications (using multi-app Saga patterns). You can read more on two-way syncing below. @@ -72,7 +72,7 @@ adaptors at the moment, and anyone is free to build or enhance them. ### Operation -An [operation](/documentation/build/steps/operations) is the sub-task inside a job. For +An [operation](/documentation/jobs/operations) is the sub-task inside a job. For example, a job for loading data to DHIS2 might include 3 separate operations: 1. Create a new "program". diff --git a/versioned_docs/version-legacy/instant-openhie.md b/versioned_docs/version-legacy/instant-openhie.md index ed8533e31b6..72b510e8536 100644 --- a/versioned_docs/version-legacy/instant-openhie.md +++ b/versioned_docs/version-legacy/instant-openhie.md @@ -6,7 +6,7 @@ title: Instant OpenHIE Please note that OpenFn/microservice and OpenFn/devtools are being deprecated and replaced by OpenFn/lightning, When Lighting is released, it may be used -within Instant OpenHIE (instead of microservice) as an OpenHIE-compliant workflow engine that can interface with the OpenHIE Interoperability Layer ([learn more](/documentation#openfn-v2-lightning-#standards-and-compliance-matter)). +within Instant OpenHIE (instead of microservice) as an OpenHIE-compliant workflow engine that can interface with the OpenHIE Interoperability Layer ([learn more](/documentation/about-lightning#standards-and-compliance-matter)). ::: @@ -291,10 +291,10 @@ These two methods are detailed below: [openhiestack]: https://openhim.readthedocs.io/en/latest/implementations/openhie.html [openhiearchitecture]: https://wiki.ohie.org/pages/viewpage.action?pageId=8454157 [openhim]: http://openhim.org/ -[jobs]: /documentation/build/workflows/ +[jobs]: /documentation/build/jobs/ [mediators]: http://openhim.org/mediator-library/ [demorepo]: https://github.com/OpenFn/instant-demo -[openfnmicroservice]: /documentation/deploy/portability/ +[openfnmicroservice]: /documentation/microservice/home/ [digitalsquare]: https://digitalsquare.org/ [fhir]: https://fhir.org/ [hapifhir]: https://hapifhir.io/ @@ -311,13 +311,13 @@ These two methods are detailed below: [jembi]: https://www.jembi.org/ [cred]: /documentation/build/credentials/ [trig]: /documentation/build/triggers/ -[devtools]: https://github.com/OpenFn/devtools +[devtools]: /documentation/devtools/home/#configure-an-openfn-project [testfile]: https://github.com/OpenFn/instant-demo/blob/main/test.js [instantdemo]: https://github.com/OpenFn/instant-demo [samplecred]: https://github.com/OpenFn/instant-demo/blob/main/openfn/docker/config/project.yaml#L165-L167 [openfncli]: https://github.com/OpenFn/devtools/#configure-an-openfn-project [demoexpr]: https://github.com/OpenFn/instant-demo/tree/main/expressions -[jobexpr]: /documentation/build/workflows/#a-basic-expression +[jobexpr]: /documentation/build/jobs/#a-basic-expression [sampleyaml]: https://github.com/OpenFn/instant-demo/blob/main/openfn/docker/config/project.yaml [curl]: https://curl.se/ [studio]: /documentation/jobs/job-studio/ diff --git a/versioned_docs/version-legacy/intro/home.md b/versioned_docs/version-legacy/intro/home.md index b51db2916e3..e0b21b8da27 100644 --- a/versioned_docs/version-legacy/intro/home.md +++ b/versioned_docs/version-legacy/intro/home.md @@ -37,7 +37,7 @@ Some OpenFn use cases are: ## Who is it built by? -OpenFn products are built by the [Open Function Group](/documentation) and +OpenFn products are built by the [Open Function Group](/documentation/about) and a growing community of open-source contributors. ## Our products @@ -47,7 +47,7 @@ users the freedom to switch between any and all of the OpenFn products. All OpenFn products, other than the OpenFn iPaaS are part of the free and open-source -[**OpenFn Integration Toolkit**](/documentation#our-products). +[**OpenFn Integration Toolkit**](/documentation/getting-started/integration-toolkit). This Toolkit is a **Digital Public Good** (a "DPG") recognized in the [DPG Registry](https://digitalpublicgoods.net/registry/) and Digital Square's [Global Goods Guidebook](https://digitalsquare.org/resourcesrepository/global-goods-guidebook). diff --git a/versioned_docs/version-legacy/jobs/job-design-intro.md b/versioned_docs/version-legacy/jobs/job-design-intro.md index 7a84ff64e70..b5a6966dd92 100644 --- a/versioned_docs/version-legacy/jobs/job-design-intro.md +++ b/versioned_docs/version-legacy/jobs/job-design-intro.md @@ -10,7 +10,7 @@ other words, mapping data elements from one system to the other. Designing a job really just means clearly defining the “rules” for data element mapping. We'll walk through the main steps using Kobo Toolbox as an example -source system and a Postgres database as destination but check out the [integration design](/documentation/design/design-overview/) page for more details on data flow diagrams and mappings. +source system and a Postgres database as destination but check out the [integration design](/documentation/design/design-quickstart/) page for more details on data flow diagrams and mappings. Step 1: Map your data flows diff --git a/versioned_docs/version-legacy/jobs/job-studio.md b/versioned_docs/version-legacy/jobs/job-studio.md index 54a7a98a4f0..ea2a11803f5 100644 --- a/versioned_docs/version-legacy/jobs/job-studio.md +++ b/versioned_docs/version-legacy/jobs/job-studio.md @@ -3,7 +3,7 @@ title: The OpenFn Job Studio --- The OpenFn Job Studio allows you create and test jobs on the platform with easy -access to documentation of [adaptors](/documentation/build/workflows#adaptors), +access to documentation of [adaptors](/documentation/build/jobs#adaptors), matching [messages](/documentation/build/inbox) and real-time logs. ```mdx-code-block diff --git a/versioned_docs/version-legacy/manage/platform-mgmt.md b/versioned_docs/version-legacy/manage/platform-mgmt.md index ce7756b4470..f54f8318333 100644 --- a/versioned_docs/version-legacy/manage/platform-mgmt.md +++ b/versioned_docs/version-legacy/manage/platform-mgmt.md @@ -4,7 +4,7 @@ title: Project Management :::important -Currently, this section is specific to **OpenFn/platform**. +Currently, this section is specific to **OpenFn/platform v1**. ::: @@ -39,7 +39,7 @@ steps below: :::info Note that once a job is **switched on**, OpenFn will run it automatically, as -[configured](/documentation/build/workflows). If you do not want a job to be run +[configured](/documentation/build/jobs). If you do not want a job to be run automatically, by OpenFn, then turn it **off**. ::: @@ -198,14 +198,14 @@ The **four configuration steps** include giving the job a name, defining what [authentication](/documentation/build/credentials) details. The **expression editor** is the area where you write your -[job expression](/documentation/build/workflows/#composing-job-expressions). Fill-in +[job expression](/documentation/jobs/#composing-job-expressions). Fill-in all the details, and click on the **Save** icon in the top-right corner to save your job's configuration changes. #### Inspecting job's initial state This feature allows you to view the -[initial state](/documentation/build/steps/state/#initial-state) of a selected job. +[initial state](/documentation/jobs/state/#initial-state) of a selected job. Note that this feature is currently only available for [message-triggered jobs](/documentation/build/triggers#message-filter-triggers). @@ -219,7 +219,7 @@ as data path for the job's expression. #### Accessing inline adaptor documentation For a selected adaptor, OpenFn allows you to view documentation and code -examples for each [adaptor operation](/documentation/build/steps/operations). +examples for each [adaptor operation](/documentation/jobs/operations). To view adaptor documentation, click on the `documentation icon`(first icon) on the top-right corner of the `Expression Pane`. @@ -806,12 +806,12 @@ finished working on the first. #### Exporting Project Config - OpenFn allows you to run your project as a - [Microservice](/documentation/deploy/portability/) . + [Microservice](/documentation/microservice/home/) . - There are two options for exporting the project config used in OpenFn Microservice. Exporting as `project.yaml` will provide you with a `YAML` file that can be used to run this project with - [OpenFn/engine](/documentation/deploy/portability/), - [OpenFn/microservice](/documentation/deploy/portability/), or for use in + [OpenFn/engine](/documentation/microservice/home/), + [OpenFn/microservice](/documentation/microservice/home/), or for use in another OpenFn/platform space. - Exporting as `microservice.zip` will prepare a `ZIP` file with `openfn/microservice:latest` (from hub.docker.com) and a your `YAML` file diff --git a/versioned_docs/version-legacy/manage/troubleshooting-tips-on-platform.md b/versioned_docs/version-legacy/manage/troubleshooting-tips-on-platform.md index cce621c6afd..c9ba921ac21 100644 --- a/versioned_docs/version-legacy/manage/troubleshooting-tips-on-platform.md +++ b/versioned_docs/version-legacy/manage/troubleshooting-tips-on-platform.md @@ -12,7 +12,7 @@ Currently, this section is specific to **OpenFn/platform**. ## Runs One of the most helpful pages for troubleshooting on OpenFn platform is the -[Activity History](/documentation/get-started/terminology/#activity-history). +[Activity History](/documentation/getting-started/terminology/#activity-history). This pages provides a list of all of the runs executed in a project and always marks any failed runs red or yellow. Project administrators can troubleshoot errors by clicking into the run to review the run details. Keep reading for all @@ -23,7 +23,7 @@ troubleshooting! Every run will have an exit code. The exit code is a way for OpenFn to classify the run status and can help you troubleshoot errors. Learn more about OpenFn -exit codes and what each one means [here](/documentation/monitor-history/troubleshooting). +exit codes and what each one means [here](/documentation/jobs/errors). ### The time it took for the job to fail @@ -103,7 +103,7 @@ History, and Search Console. troubleshooting! Learn more about inbox filtering [here](/documentation/manage/platform-mgmt/#inbox). -2. **[Activity history](/documentation/get-started/terminology/#activity-history)** - +2. **[Activity history](/documentation/getting-started/terminology/#activity-history)** - As discussed above, the activity history records all runs for the current project. It has similar search and filtering capabilities as the inbox except it doesn't require valid JSON in the search box. Use the search in activity diff --git a/versioned_docs/version-legacy/openfn-roadmap.md b/versioned_docs/version-legacy/openfn-roadmap.md index 4144cb16091..c5a53b6f4e1 100644 --- a/versioned_docs/version-legacy/openfn-roadmap.md +++ b/versioned_docs/version-legacy/openfn-roadmap.md @@ -20,7 +20,7 @@ product suite. This includes OpenFn/`Lightning`, `Adaptors`, and `Docs`. OpenFn/Lightning is the fully open-source workflow automation platform at the core of the OpenFn Digital Public Good (learn more about the product -[here](/documentation#openfn-v2-lightning-)). +[here](/documentation/about-lightning)). | **Feature** | **`Status`** | **Target Timeline** | **Related Links** | **Description** | | ---------------------------------------------------------------------- | ------------ | ------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | @@ -53,7 +53,7 @@ workflow engine, enable automated workflows that cut across digital systems. | **Feature** | **`Status`** | **Target Timeline** | **Related Links** | **Description** | | ------------------------------------------------------------------------------------------------- | ------------ | ------------------- | ------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| 1. Enhancements to [`FHIR`](http://www.hl7.org/fhir/) & [`OpenHIM`](http://openhim.org/) adaptors | Not Started | Q3 2023 | See existing adaptors for [FHIR](/adaptors/packages/fhir-docs) and [OpenHIM](/adaptors/packages/openhim-docs) | To rebuild the existing 2021 [OpenFn Instant-OpenHIE reference demo](/documentation/get-started/standards#openhie-standard-architecture) to highlight the exchange of data between existing non-FHIR digital health tools and a HAPI FHIR server. (OpenFn Lightning is OpenHIE-compliant and can be used as a workflow engine for the OpenHIE Interoperability layer - [learn more here](/documentation#openfn-v2-lightning-#standards-and-compliance-matter).) We also want to demonstrate data exchange between existing non-FHIR digital health tools and key components of Google’s [Open Health Stack](https://developers.google.com/open-health-stack) and [Cloud Healthcare API](https://cloud.google.com/healthcare-api/docs/concepts/fhir) | +| 1. Enhancements to [`FHIR`](http://www.hl7.org/fhir/) & [`OpenHIM`](http://openhim.org/) adaptors | Not Started | Q3 2023 | See existing adaptors for [FHIR](/adaptors/packages/fhir-docs) and [OpenHIM](/adaptors/packages/openhim-docs) | To rebuild the existing 2021 [OpenFn Instant-OpenHIE reference demo](/documentation/instant-openhie) to highlight the exchange of data between existing non-FHIR digital health tools and a HAPI FHIR server. (OpenFn Lightning is OpenHIE-compliant and can be used as a workflow engine for the OpenHIE Interoperability layer - [learn more here](/documentation/about-lightning#standards-and-compliance-matter).) We also want to demonstrate data exchange between existing non-FHIR digital health tools and key components of Google’s [Open Health Stack](https://developers.google.com/open-health-stack) and [Cloud Healthcare API](https://cloud.google.com/healthcare-api/docs/concepts/fhir) | | 2. Add "magic" functions to existing, in-demand adaptors | Not started | Q3 2023 | [Issue 243](https://github.com/OpenFn/adaptors/issues/243) | Add functions, dynamic lists, and shortcuts to fast-track workflow configuration for key adaptors including HTTP, [DHIS2](https://dhis2.org/), [CommCare](https://www.dimagi.com/commcare/), & [OpenMRS](https://openmrs.org/) | | 3. New [`OpenMRS`](https://openmrs.org/) adaptor version | Not started | Q3 2023 | [See existing adaptor docs](/adaptors/packages/openmrs-readme) | To ensure compliance with OpenMRS v3 | | 4. Enhancements to the [`OCL`](https://openconceptlab.org/) adaptor | Not started | Q3 2023 | [See existing adaptor docs](/adaptors/packages/ocl-readme) | To ensure that mappings stored in OCLs can be more easily access and processed as inputs in OpenFn/Lightning workflows | @@ -62,7 +62,7 @@ workflow engine, enable automated workflows that cut across digital systems. | **Feature** | **`Status`** | **Target Timeline** | **Related Links** | **Description** | | ----------------------------------------------------------- | ------------ | ------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| 1. OpenFn and the [OpenHIE](https://ohie.org/) architecture | Planned | Q2 2023 | [See current docs](/documentation#openfn-v2-lightning-#standards-and-compliance-matter) | New page dedicated to how OpenHIE aligns with OpenHIE architecture; expansion of the existing small section on standards | +| 1. OpenFn and the [OpenHIE](https://ohie.org/) architecture | Planned | Q2 2023 | [See current docs](/documentation/about-lightning#standards-and-compliance-matter) | New page dedicated to how OpenHIE aligns with OpenHIE architecture; expansion of the existing small section on standards | | 2. New Lightning User Guidance | Not started | Q3 2023 | To be hosted on docs.openfn.org | New documentation, videos, and other user guidance on how to use OpenFn/Lightning and how to migrate existing OpenFn/platform projects to Lightning (the new OpenFn "v2") | | 3. Template [FHIR](http://www.hl7.org/fhir/) Workflows | Planned | Q3 2023 | To be hosted on demo.openfn.org | OpenFn can already help achieve FHIR compliance, but we will build and document reference/template workflows to demonstrate how OpenFn/Lightning can automate data exchange, registration, and/or reporting workflows between non-FHIR data systems and FHIR APIs. | | 4. Template Alerting Workflows | Not started | Q4 2023 | [See OpenHIE docs](https://guides.ohie.org/arch-spec/introduction/alerting-sending-reminders-or-information); to be hosted on demo.openfn.org | To demonstrate how OpenFn can facilitate one-way communication to a client or provider listed in the HIE (from the OpenHIE standard spec) | diff --git a/versioned_docs/version-legacy/portability-versions.md b/versioned_docs/version-legacy/portability-versions.md index aef89fad1fb..f824370d7ba 100644 --- a/versioned_docs/version-legacy/portability-versions.md +++ b/versioned_docs/version-legacy/portability-versions.md @@ -10,7 +10,7 @@ be used to import or export projects between OpenFn/platform and OpenFn/engine. The portability specification v4 defines how entire projects (groups of workflows with their associated triggers, credentials and jobs) can be represented as code. This specification has been written for -[Lightning](/documentation#our-products/#lightning-coming-soon), +[Lightning](/documentation/getting-started/integration-toolkit/#lightning-coming-soon), the fully open source webb app which extends the OpenFn DPG. It aims to (a) improve developer experience, allowing them to build and test workflows locally; (b) enable version control and an audit trail of project changes; and (c) enable From 264f704a3c0d43c6539c4f27728352e6427132e4 Mon Sep 17 00:00:00 2001 From: aleksa-krolls Date: Mon, 12 Feb 2024 18:53:17 +0200 Subject: [PATCH 5/8] cleaning up sidebar and deprecated pages --- docs/build/steps/errors.md | 84 ----------------------------- docs/build/steps/test-steps.md | 22 -------- docs/contribute/roadmap.md | 69 ------------------------ docs/monitor-history/work-orders.md | 0 sidebars-main.js | 20 +++---- 5 files changed, 10 insertions(+), 185 deletions(-) delete mode 100644 docs/build/steps/errors.md delete mode 100644 docs/build/steps/test-steps.md delete mode 100644 docs/contribute/roadmap.md delete mode 100644 docs/monitor-history/work-orders.md diff --git a/docs/build/steps/errors.md b/docs/build/steps/errors.md deleted file mode 100644 index c313f1ad1a0..00000000000 --- a/docs/build/steps/errors.md +++ /dev/null @@ -1,84 +0,0 @@ ---- -title: Exit Codes & Errors ---- - -## About errors - -Errors are your friends. The most important thing you can do when encountering -an error in any step of a data integration project is to _read_ what's on the -screen. While this may sound obvious, it's very easy to see a big block of -technical language and switch off. - -Often, there are simple business reasons that a run is failing and they can be -identified from the error messages displayed in the logs by @openfn/core. - -## Standard Exit Codes - -### 0: Success - -Exit code `0` is a success (run succeeded, e.g. a destination system responded -with a `200`) - -### 1: Error - -Exit code `1` is a normally-handled error (run failed normally, e.g. a -destination system responded with a `4XX`, `5XX`, or some specialized -`RequiredFieldMissing` error.) - -### 2: Timeout - -Exit code `2` means that your run timed out. It exceeded the timeout you set for -your job, or if you're using the hosted platform on a non-enterprise plan, it -exceeded `100` seconds. - -### 10: Core Error - -Exit code `10` means there was an error in `@openfn/core/cli.js execute`. It's -possible that you job can't be run how it's written, but that various validation -checks failed to warn you earlier. - -### 134: Out of memory - -This is a standard out of memory error from the NodeVM. See -[NodeVM memory limits](#nodevm-limits) below. - -## Special Exit Codes (Platform) - -The OpenFn platform controls the execution of all of your steps via the -ErlangVM. (Learn about Erlang [here](https://www.erlang.org/).) The following -exit codes are applied at the level of this controlling VM, rather than down -inside your run's NodeVM. - -### 3: Failed to start - -Exit code `3` means the run could not be started due to an Erlang error. This -could relate to network traffic, but very rare as an error which takes place -_before_ the run is started will be retried—with an exponential backoff—for a -very long time. - -### 4: The NodeVM is unresponsive - -Exit code `4` means that the NodeVM running your job became unresponsive. It -attempted to exit after the timeout but couldn't, so we shut down the process -from the controlling ErlangVM. - -### 5: Elixir/ErlangVM Error - -Exit code `5` means we encountered an unexpected error during the execution of -your job which could only be caught by the controlling ErlangVM. Errors like -this are very rare and trigger an internal audit by the OpenFN engineering team. - -### 6: Aborted by project administrator - -Exit code `6` means that a run created and queued for execution but then -subsequently aborted by request of an administrator or owner of that project. - -### 11: Node.js Error - -Exit code `11` means that there was an error in the NodeVM execution but the -exit code itself couldn't be captured by our application. - -## Limits - -We've shifted this content to a dedicated -[limits](/documentation/build/limits) page. diff --git a/docs/build/steps/test-steps.md b/docs/build/steps/test-steps.md deleted file mode 100644 index 71783ad443f..00000000000 --- a/docs/build/steps/test-steps.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -title: Configure Steps ---- - -## Run & Test Steps - -When running Steps to test the configuration, every Run will have an initial -state (which may contain an `Input`) and results in a final state that will -include `Logs` and an `Output`. - -- `Input` - Data (JSON) that is used as the starting Input for a Step to utilise - in its run. An Input can exist for a Work Order and individual Steps within a - Run, though it is possible for either to exist without an Input. -- `Output` - Data (JSON) that is created as the Output of a Step's execution. An - Output can exist for a Work Order and individual jobs within a run, and - typically contains the data sent to the target app. -- `Logs` - A record generated by the workflow execution engine that details the - activities performed when running a Workflow or individual Step. - -See [Edit Steps](/docs/build/steps/step-editor.md) for more on making changes -and testing, and see [this article](/docs/build/steps/state.md) for more on the -concept of "state" when writing Jobs and building OpenFn Workflows. \ No newline at end of file diff --git a/docs/contribute/roadmap.md b/docs/contribute/roadmap.md deleted file mode 100644 index d99bee57dd9..00000000000 --- a/docs/contribute/roadmap.md +++ /dev/null @@ -1,69 +0,0 @@ ---- -title: Documentation Roadmap ---- - -## Visit the public [documentation roadmap](https://github.com/orgs/OpenFn/projects/1?card_filter_query=repo%3Aopenfn%2Fdocs) on github. - -We're constantly working to improve the documentation on OpenFn, particularly -around the open source integration toolkit. Visit the documentation roadmap on -Github to see what we're working on. - -:::tip - -Visit -[**the documentation roadmap**](https://github.com/orgs/OpenFn/projects/1?card_filter_query=repo%3Aopenfn%2Fdocs) -to view the documentation roadmap. - -Below is merely a static list that will be updated far less frequently than the -actual docs issues on Github. - -::: - -## Planned Sections/Enhancements - -### Foundational Concepts - -A page or set of pages that reviews concepts that are essentially prerequisite -to using OpenFn or another interoperability platform. - -### The anatomy of an integration (title subject to change) - -Envisioned as a primarily visual page that outlines the constituent parts of -every integration to equip OpenFn users with a solid grounding of what an -integration really is - -### Integrating using OpenFn - -Either a subpage of the structure page or its own page subsequent to; this maps -the foundational concepts above to jobs, triggers, runs, etc. We will only -introduce OpenFn-specific terminology after we establish a common frame of -reference. In some ways this is just an edit of the current Getting Started -page. - -### What Does it Mean to be Ready? - -Detail our OFG consulting team’s implementation process, including the various -places that data mapping is referenced to do a step-by-step “pre-job-writing” -walkthrough - -### Creation of documentation/tutorial “pathways” - -Presenting guides and for new users and new devs from existing documentation -resources to flatten the learning curve - -### Quickstart - -Rewrite to be dev-centered; should read as a page for users who understand the -above already and are ready to dive into technical setup - -### Project walk-through - -Revise to incorporate the below app-specific tutorials in a cohesive manner - -### How to integrate CommCare with Salesforce - -The Project walkthrough, but specific to these two tools. - -### How to integrate DHIS2 and CommCare - -### How to integrate Kobo Toolbox and a custom Postgres database diff --git a/docs/monitor-history/work-orders.md b/docs/monitor-history/work-orders.md deleted file mode 100644 index e69de29bb2d..00000000000 diff --git a/sidebars-main.js b/sidebars-main.js index 74bfaf0cd02..3d33cb103ec 100644 --- a/sidebars-main.js +++ b/sidebars-main.js @@ -10,22 +10,19 @@ module.exports = { 'get-started/standards', 'get-started/security-compliance', 'get-started/security', - // 'get-started/implementation-checklist', - // + // 'get-started/implementation-checklist', //TODO: Add back after Aicha's updates ], }, { type: 'category', label: 'Design Workflows', items: [ - //'design/overview', 'design/design-overview', 'design/discovery', 'design/design-workflow', 'design/api-discovery', 'design/mapping-specs', 'design/workflow-specs', - //'design/discovery' ], }, { @@ -43,8 +40,9 @@ module.exports = { 'build/steps/step-editor', 'build/steps/step-design-intro', 'build/paths', + 'build/credentials', 'build/limits', - //'build/troubleshooting', + 'build/troubleshooting', { type: 'category', label: 'Jobs', @@ -59,7 +57,6 @@ module.exports = { 'build/steps/working-with-branches', ], }, - //============ END =================// ], }, { @@ -73,13 +70,17 @@ module.exports = { 'build-for-developers/jobs', 'build-for-developers/build-with-api', 'build-for-developers/security-for-devs', - //'build-for-developers/for-devs' ], }, { type: 'category', label: 'Deploy', - items: ['deploy/options', 'deploy/requirements', 'deploy/portability'], + items: [ + 'deploy/options', + 'deploy/requirements', + 'deploy/portability', + 'deploy/portability-versions', + ], }, { type: 'category', @@ -119,8 +120,7 @@ module.exports = { label: 'Contribute', items: [ 'contribute/openfn-roadmap', - // 'contribute/roadmap', - // 'contribute/writing-code', + 'contribute/writing-code', 'contribute/writing-docs', 'contribute/style-guide', ], From ab57d7d01ee551019b17c0a86a047baebb1963c5 Mon Sep 17 00:00:00 2001 From: Taylor Downs Date: Tue, 13 Feb 2024 07:31:11 +0000 Subject: [PATCH 6/8] legacy docs link fix --- .../version-legacy/about-lightning.md | 6 ++-- .../version-legacy/build/example-build.md | 2 +- versioned_docs/version-legacy/build/inbox.md | 2 +- versioned_docs/version-legacy/build/jobs.md | 2 +- .../build/lightning-quick-start.md | 2 +- versioned_docs/version-legacy/cli.md | 4 +-- versioned_docs/version-legacy/core.md | 4 +-- .../version-legacy/deploy/requirements.md | 2 +- .../design/design-quickstart.md | 4 +-- .../version-legacy/devtools/home.md | 4 +-- .../commcare-project-walkthrough.md | 22 ++++++------- .../getting-started/glossary.md | 2 +- .../implementation-checklist.md | 6 ++-- .../getting-started/integration-toolkit.md | 2 +- .../getting-started/security.md | 2 +- .../so-you-want-to-integrate.mdx | 6 ++-- .../getting-started/terminology.md | 16 +++++----- .../version-legacy/instant-openhie.md | 26 ++++++++------- versioned_docs/version-legacy/intro/home.md | 8 ++--- .../version-legacy/jobs/editing_locally.md | 6 ++-- versioned_docs/version-legacy/jobs/errors.md | 6 ++-- .../version-legacy/jobs/job-design-intro.md | 2 +- .../version-legacy/jobs/job-studio.md | 4 +-- .../jobs/working_with_branches.md | 4 +-- .../version-legacy/manage/platform-mgmt.md | 32 +++++++++---------- .../troubleshooting-tips-on-platform.md | 14 ++++---- .../version-legacy/openfn-roadmap.md | 8 ++--- .../version-legacy/portability-versions.md | 2 +- .../version-legacy/release-notes.md | 2 +- 29 files changed, 102 insertions(+), 100 deletions(-) diff --git a/versioned_docs/version-legacy/about-lightning.md b/versioned_docs/version-legacy/about-lightning.md index c422fdc5da9..d66cb0c09ac 100644 --- a/versioned_docs/version-legacy/about-lightning.md +++ b/versioned_docs/version-legacy/about-lightning.md @@ -87,7 +87,7 @@ integrations to make sure no request goes unprocessed. ## Roadmap -See the [Lightning Roadmap](/documentation/contribute/openfn-roadmap) for a detailed list +See the [Lightning Roadmap](./openfn-roadmap.md) for a detailed list of features that are in the backlog, planned, and/or in development for the OpenFn Digital Public Good. @@ -144,7 +144,7 @@ workflow engine. Learn more via the following resources: - Check out OpenFn's entry in the [OpenHIE Reference Technologies page](https://wiki.ohie.org/display/documents/Reference+Technologies). - Explore the OpenFn-Instant OpenHIE - [reference demo implementation](/documentation/get-started/standards#openhie-standard-architecture). + [reference demo implementation](./instant-openhie.md). - Learn more about the GovStack [Workflow Building Block](https://govstack.gitbook.io/bb-workflow/2-description) specification. @@ -322,7 +322,7 @@ location—guaranteeing that no data ever leaves the selected country. To help our users adopt best practices when it comes to the design of their integrations, we’ve published a -[Security Guidebook for data integration implementations](/documentation/get-started/security). +[Security Guidebook for data integration implementations](./getting-started/security.md). ## Get involved diff --git a/versioned_docs/version-legacy/build/example-build.md b/versioned_docs/version-legacy/build/example-build.md index 68781b82cf6..f99b6c58388 100644 --- a/versioned_docs/version-legacy/build/example-build.md +++ b/versioned_docs/version-legacy/build/example-build.md @@ -139,7 +139,7 @@ snippet comes into your inbox. Save your trigger. You should see a confirmation message “Found x matching messages”. To see the data from your last message inside the -[initial state](/documentation/jobs/state), drag the +[initial state](../jobs/state.md), drag the **Expression** panel to the right. ![trigger message](/img/4.3_trigger_message.png 'View a matching trigger message in initial state') diff --git a/versioned_docs/version-legacy/build/inbox.md b/versioned_docs/version-legacy/build/inbox.md index 389ae51b8d8..09273b28985 100644 --- a/versioned_docs/version-legacy/build/inbox.md +++ b/versioned_docs/version-legacy/build/inbox.md @@ -58,7 +58,7 @@ operations in step 4 completed successfully (what do you count as a success with these various custom actions, by the way?) you should consider implementing a SAGA pattern, whereby after all this processing is complete you trigger another request back to the initial system reporting on the downstream tasks. This can -be done in OpenFn with [Flow Triggers](/documentation/jobs/multiple-operations). +be done in OpenFn with [Flow Triggers](../jobs/multiple-operations.md). ## Synchronous vs. Asynchronous Processing diff --git a/versioned_docs/version-legacy/build/jobs.md b/versioned_docs/version-legacy/build/jobs.md index 6ae92379689..13d0147bc00 100644 --- a/versioned_docs/version-legacy/build/jobs.md +++ b/versioned_docs/version-legacy/build/jobs.md @@ -207,7 +207,7 @@ language-packs. #### each() -Read more about each here: [The each(...) operation](/documentation/jobs/each) +Read more about each here: [The each(...) operation](../jobs/each.md) ```js each( diff --git a/versioned_docs/version-legacy/build/lightning-quick-start.md b/versioned_docs/version-legacy/build/lightning-quick-start.md index c2b70e769e8..2c372d2b892 100644 --- a/versioned_docs/version-legacy/build/lightning-quick-start.md +++ b/versioned_docs/version-legacy/build/lightning-quick-start.md @@ -128,7 +128,7 @@ state (which contains your input) to use. When you need to use data that comes from your webhook trigger (data sent from your external system), cron trigger, or a previous job you can find it in -`state`. Learn more [here](/documentation/jobs/state/). +`state`. Learn more [here](../jobs/state.md/). ::: diff --git a/versioned_docs/version-legacy/cli.md b/versioned_docs/version-legacy/cli.md index a88916192e8..2fa3930e493 100644 --- a/versioned_docs/version-legacy/cli.md +++ b/versioned_docs/version-legacy/cli.md @@ -39,7 +39,7 @@ to use and understand OpenFn. :::caution Looking for a way to execute jobs from OpenFn v1 locally? Use Core! If you're looking for a way to execute jobs running on the OpenFn v1 platform, -please see the documentation for **[@openfn/core](/https://github.com/OpenFn/core)** and +please see the documentation for **[@openfn/core](https://github.com/OpenFn/core)** and [Devtools](https://github.com/OpenFn/devtools). ::: @@ -811,7 +811,7 @@ between systems in a structured and automated way. _For example, if you have two jobs in your workflow (GET users from system A & POST users to system B), you can set up your workflow to run all jobs in sequence from start to finish. This imitates the -[flow trigger patterns](https://docs.openfn.org/documentation/build/triggers#flow-triggers) +[flow trigger patterns](./build/triggers.md#flow-triggers) on the OpenFn platform where a second job should run after the first one succeeds, respectively, using the data returned from the first job. “_ diff --git a/versioned_docs/version-legacy/core.md b/versioned_docs/version-legacy/core.md index be0a0607041..46369645982 100644 --- a/versioned_docs/version-legacy/core.md +++ b/versioned_docs/version-legacy/core.md @@ -20,7 +20,7 @@ governments and NGOs all over the world. Core is used in OpenFn v1 (the web platform) and by developers who want to test job execution on their local machines. It's _not_ used in Lightning (OpenFn v2) which instead makes use of the new runtime. For a local developer experience -using the new runtime, check out [CLI](/documentation/cli). +using the new runtime, check out [CLI](./cli.md). ## Why might I want to use it now? @@ -30,7 +30,7 @@ be incredibly helpful for debugging. :::tip Using the new CLI. -If you're a new OpenFn user and want to build or test jobs for Lighting (v2) and beyond in 2023, use the new [CLI](/documentation/cli) instead! +If you're a new OpenFn user and want to build or test jobs for Lighting (v2) and beyond in 2023, use the new [CLI](./cli.md) instead! ::: diff --git a/versioned_docs/version-legacy/deploy/requirements.md b/versioned_docs/version-legacy/deploy/requirements.md index 3c24072d9af..da2dac8029e 100644 --- a/versioned_docs/version-legacy/deploy/requirements.md +++ b/versioned_docs/version-legacy/deploy/requirements.md @@ -5,7 +5,7 @@ title: Requirements ## Plan first Not sure where to start? Head back to the -["Planning"](/documentation/deploy/options) page to think about how you want to +["Planning"](./options.md) page to think about how you want to scale up your OpenFn automation projects. ## Assess your capacity diff --git a/versioned_docs/version-legacy/design/design-quickstart.md b/versioned_docs/version-legacy/design/design-quickstart.md index 21791e27d2d..98b6b51c417 100644 --- a/versioned_docs/version-legacy/design/design-quickstart.md +++ b/versioned_docs/version-legacy/design/design-quickstart.md @@ -69,7 +69,7 @@ information will be exchanged? With _whom_ (between which systems or users)? _When_ will the information be exchanged? And what are the human or automation steps that should facilitate and trigger this exchange? These business process questions are discussed in more detail on the -[So, what is an integration?](/documentation/getting-started/so-you-want-to-integrate/) +[So, what is an integration?](../getting-started/so-you-want-to-integrate.mdx) page. :::tip @@ -189,5 +189,5 @@ solution, as well as memorialize the business decisions and agreements made by implementing partners. Share this documentation with any technical implementation team, or check out -the [Build](/documentation/build/jobs) documentation section to learn how to +the [Build](../build/jobs.md) documentation section to learn how to implement these design specifications using OpenFn. diff --git a/versioned_docs/version-legacy/devtools/home.md b/versioned_docs/version-legacy/devtools/home.md index 98db81af208..1c8d7a1aafc 100644 --- a/versioned_docs/version-legacy/devtools/home.md +++ b/versioned_docs/version-legacy/devtools/home.md @@ -5,7 +5,7 @@ title: Devtools :::caution Devtools is deprecated Please note that [OpenFn/devtools](https://github.com/OpenFn/devtools) are being -deprecated and replaced by [OpenFn/cli](/documentation/cli). Learn more about +deprecated and replaced by [OpenFn/cli](../cli.md). Learn more about CLI [github.com/OpenFn/cli/](https://github.com/OpenFn/kit/tree/main/packages/cli) @@ -22,7 +22,7 @@ The [Devtools](https://github.com/OpenFn/devtools) repo is a collection of bash and Node scripts, as well as a _suggested_ (but not necessary) directory structure for working with OpenFn jobs and adaptors. -To run OpenFn jobs locally, you only need [Core](/https://github.com/OpenFn/core) and at +To run OpenFn jobs locally, you only need [Core](https://github.com/OpenFn/core) and at least one adaptor, e.g. [language-http](https://github.com/OpenFn/language-http) and you may prefer to install core globally via `npm install -g @openfn/core` diff --git a/versioned_docs/version-legacy/getting-started/commcare-project-walkthrough.md b/versioned_docs/version-legacy/getting-started/commcare-project-walkthrough.md index 75708d39213..960d14aac5f 100644 --- a/versioned_docs/version-legacy/getting-started/commcare-project-walkthrough.md +++ b/versioned_docs/version-legacy/getting-started/commcare-project-walkthrough.md @@ -9,8 +9,8 @@ title: minute!) - You have checked out our glossary and have an understanding of basic OpenFn and API terminology. Check out the pages below to get started - - [OpenFn Concepts](/documentation/getting-started/terminology/) - - [A glossary for data integration](/documentation/getting-started/glossary/) + - [OpenFn Concepts](../getting-started/terminology.md) + - [A glossary for data integration](../getting-started/glossary.md) - You have a CommCare application with at least one form configured. This is your source system. - You have a PostgreSQL database configured. This is your destination system. @@ -110,14 +110,14 @@ In the credential `JSON Configuration`, add your credential as follows: :::tip -Check out [this](/documentation/getting-started/terminology/#inbox) docs page on +Check out [this](../getting-started/terminology.md/#inbox) docs page on how to find your OpenFn inbox URL to fill in the configuration above. ::: Now that you've configured the job Trigger and Credential to authenticate… -4. **Configure a new job. Note that this job will use the HTTP adaptor in order +1. **Configure a new job. Note that this job will use the HTTP adaptor in order to connect with the CommCare REST API.** ![configure_job_cc](/img/configure_job_cc.gif) @@ -213,20 +213,20 @@ there are 2:** configured the database [like this](https://docs.google.com/spreadsheets/d/1pi_oxImakhtaCCCIENkjTPZeuyWhpFEcNmH7hfvTBgo/edit?usp=sharing) to capture the CommCare form data. Check out the - [design quickstart](/documentation/design/design-quickstart#3-map-data-elements-to-be-exchanged) + [design quickstart](../design/design-quickstart.md#3-map-data-elements-to-be-exchanged) for how to create your own `mapping specification document` to map data elements to be exchanged. ![db_config](/img/db_config.png) -2. **Create a new message filter trigger, to run our second job for every new +1. **Create a new message filter trigger, to run our second job for every new patient record received in the OpenFn inbox.** Learn more about message filter triggers - [here](/documentation/build/triggers/#message-filter-triggers). + [here](../build/triggers.md#message-filter-triggers). ![create_new_trgger_db](/img/create_new_trgger_db.gif) -3. **Create a PostgreSQL credential which will be used by the job to +1. **Create a PostgreSQL credential which will be used by the job to authenticate with the database.** ![add_credential_postgres](/img/add_credential_postgres.gif) @@ -259,19 +259,19 @@ upsert('patient', 'ON CONSTRAINT patient_pk', { Feel free to modify the code above to reflect your CommCare and database configuration according to your mapping specifications. Check out this -[page](/documentation/jobs/job-studio#job-studio-features) for how to copy the +[page](../jobs/job-studio.md#job-studio-features) for how to copy the dataValue for source data fields in the OpenFn job studio. :::tip Check out the -[design quickstart](/documentation/design/design-quickstart#3-map-data-elements-to-be-exchanged) +[design quickstart](../design/design-quickstart.md#3-map-data-elements-to-be-exchanged) for how to create your own `mapping specification document` to map data elements to be exchanged. ::: -6. **Save and turn on the job** +1. **Save and turn on the job** ![save_db_job](/img/save_db_job.gif) diff --git a/versioned_docs/version-legacy/getting-started/glossary.md b/versioned_docs/version-legacy/getting-started/glossary.md index d57aa6e204a..59d3ffb1a3b 100644 --- a/versioned_docs/version-legacy/getting-started/glossary.md +++ b/versioned_docs/version-legacy/getting-started/glossary.md @@ -116,7 +116,7 @@ data to a destination system. ## Webhook -A [webhook](/documentation/source-apps#standard-webhook-configuration) (also called a web +A [webhook](../source-apps.md#standard-webhook-configuration) (also called a web callback or HTTP push API — thanks [SendGrid](https://sendgrid.com/blog/whats-webhook/)!) is a feature of an application that allows pushing. It's often configured to notify some diff --git a/versioned_docs/version-legacy/getting-started/implementation-checklist.md b/versioned_docs/version-legacy/getting-started/implementation-checklist.md index 88793ae2348..4fab0e82790 100644 --- a/versioned_docs/version-legacy/getting-started/implementation-checklist.md +++ b/versioned_docs/version-legacy/getting-started/implementation-checklist.md @@ -44,11 +44,11 @@ The XLS version of this template can be found [here](https://docs.google.com/spr ## (2) Discovery & Design - Functional Workflow Requirements - [ ] User stories documented to capture business value & desired outcomes - Learn more about user stories [here.](https://docs.openfn.org/documentation/design/design-quickstart#1-capture-requirements-as-user-stories) + Learn more about user stories [here.](../design/design-quickstart.md#1-capture-requirements-as-user-stories) - [ ] Workflow BPMN diagram capturing functional steps of the business process finalized - Learn more about diagrams & BPMN notation [here.](https://docs.openfn.org/documentation/design/design-quickstart#2-diagram-the-business-process) + Learn more about diagrams & BPMN notation [here.](../design/design-quickstart.md#2-diagram-the-business-process) - [ ] Request list of data elements from administrators of target systems - Read about mapping specs [here.](https://docs.openfn.org/documentation/design/design-quickstart#3-map-data-elements-to-be-exchanged). + Read about mapping specs [here.](../design/design-quickstart.md#3-map-data-elements-to-be-exchanged). - [ ] Data element mapping specifications finalized (functional/business-friendly version) - [ ] Client sign-offs on workflow diagram & mapping specs - [ ] Workflow assumptions documented (e.g., what human, manual steps does the workflow rely on; what are the unique identifiers) diff --git a/versioned_docs/version-legacy/getting-started/integration-toolkit.md b/versioned_docs/version-legacy/getting-started/integration-toolkit.md index 95d2124d72f..eb6496d3e96 100644 --- a/versioned_docs/version-legacy/getting-started/integration-toolkit.md +++ b/versioned_docs/version-legacy/getting-started/integration-toolkit.md @@ -97,7 +97,7 @@ Lightning is an upcoming addition to the Integration Toolkit. It is a _fully open source_ workflow automation platform designed for governments and NGOs who need a flexible solution to integrate and connect _any system_. -You can read all about it [here](/documentation/about-lightning)! +You can read all about it [here](../about-lightning.md)! ## Architecture for implementation diff --git a/versioned_docs/version-legacy/getting-started/security.md b/versioned_docs/version-legacy/getting-started/security.md index f21e28065c3..123108170c6 100644 --- a/versioned_docs/version-legacy/getting-started/security.md +++ b/versioned_docs/version-legacy/getting-started/security.md @@ -103,7 +103,7 @@ Here are the key OpenFn templates and resources referenced in the Guidebook: - [Mapping Specification Template](https://docs.google.com/spreadsheets/d/1IqTIgOzyOztEevXbgY_4uE8Y8tiHXufZXx-IyJZase0/edit#gid=1822444315) - [Solution Architecture Diagram](https://lucid.app/lucidchart/1e997197-2d67-4393-8394-a532d83561b2/edit#?templateid=fb96ae05-e288-4d1f-b3fc-2cbf7641a7cc) -- [BPMN Diagram resources](/documentation/design/design-quickstart/#use-bpmn-for-standardized-documentation) +- [BPMN Diagram resources](../design/design-quickstart.md#use-bpmn-for-standardized-documentation) - [Project Security Configuration & Go-Live Checklist](https://docs.google.com/document/d/1CbQkN7SqNmXeqt3nMTYP4ioQlTuwF2LbDkkFqhp0zsU/edit?usp=sharing) ### Communities of practice & other experts diff --git a/versioned_docs/version-legacy/getting-started/so-you-want-to-integrate.mdx b/versioned_docs/version-legacy/getting-started/so-you-want-to-integrate.mdx index f87022f73d6..554961689bb 100644 --- a/versioned_docs/version-legacy/getting-started/so-you-want-to-integrate.mdx +++ b/versioned_docs/version-legacy/getting-started/so-you-want-to-integrate.mdx @@ -15,7 +15,7 @@ this is your first go, this page can help you think through all the different ways integrations can take shape so that you have a strong understanding of what it is you really want _before_ you start writing [(or borrowing)](/adaptors/library) a -[job](/documentation/jobs/job-design-intro/). +[job](../jobs/job-design-intro.md). There are plenty of different reasons to integrate your data systems. Maybe you want one "master" view that you or your clients can trust as a source of truth. @@ -97,5 +97,5 @@ These are all very important questions to consider when designing an integration. Check out our docs on integration design to learn more about how we begin to answer these questions and more: -- [**Integration design:**](/documentation/design/design-quickstart/) -- [**Glossary for integration:**](/documentation/getting-started/glossary/) +- [**Integration design:**](../design/design-quickstart.md) +- [**Glossary for integration:**](./glossary.md) diff --git a/versioned_docs/version-legacy/getting-started/terminology.md b/versioned_docs/version-legacy/getting-started/terminology.md index 059ea2f8a74..c2db78756ce 100644 --- a/versioned_docs/version-legacy/getting-started/terminology.md +++ b/versioned_docs/version-legacy/getting-started/terminology.md @@ -23,14 +23,14 @@ With this in mind, let's check out the key terms. Please note that if you're looking for a glossary for generic terms used in data-integration (rather than this _OpenFn-specific_ stuff) head over to the -[Glossary for Integration](/documentation/getting-started/glossary) page in the +[Glossary for Integration](../getting-started/glossary.md) page in the Design section. Otherwise, read on! ## Project A project is an administrative grouping in OpenFn. In [OpenFn/microservice](https://github.com/OpenFn/microservice), it corresponds to a -[`project.yaml`](/documentation/portability#proposal-v2-latest) file. On the +[`project.yaml`](../portability.md#proposal-v2-latest) file. On the platform, it's got an owner, a billing plan, and a bunch of collaborators—different users that have been granted access to the project. In either case, a project contains jobs, triggers, credentials, and everything you @@ -44,7 +44,7 @@ Jobs are the **"what to do"** part of automation! ::: -OpenFn automation centers around [jobs](/documentation/build/jobs), which define +OpenFn automation centers around [jobs](../build/jobs.md), which define the specific series of operations (i.e., tasks) that OpenFn should perform. Jobs can be executed at certain times, when message arrive from outside systems, or when _other jobs_ succeed or fail. Think of jobs as a set of instructions you @@ -56,7 +56,7 @@ confirmation number when payment confirmation message is received etc.). :::note Jobs are Reusable Jobs are fully configurable and reusable. They can also be chained together to -create [multi-step automation](/documentation/jobs/multiple-operations) flows, +create [multi-step automation](../jobs/multiple-operations.md) flows, two-way syncs, and to keep data consistent between multiple applications (using multi-app Saga patterns). You can read more on two-way syncing below. @@ -72,7 +72,7 @@ adaptors at the moment, and anyone is free to build or enhance them. ### Operation -An [operation](/documentation/jobs/operations) is the sub-task inside a job. For +An [operation](../jobs/operations.md) is the sub-task inside a job. For example, a job for loading data to DHIS2 might include 3 separate operations: 1. Create a new "program". @@ -87,7 +87,7 @@ Triggers are the **"when to do it"** part of automation! ::: -A [trigger](/documentation/build/triggers) determines **when** to run a job +A [trigger](../build/triggers.md) determines **when** to run a job automatically. A trigger could be set up to run a job when a message arrives (this is known as a `message filter` trigger), on a cron schedule (a `cron` trigger) or based on the success or failure of _another_ job(a `flow` or `catch` @@ -102,7 +102,7 @@ Credentials are the **"How to log in"** part of automation! ::: -A [credential](/documentation/build/credentials) is used to log in to a +A [credential](../build/credentials.md) is used to log in to a destination system (e.g., Salesforce username, password & login URL) so that a job can run. Via OpenFn's security model, they are separated from the jobs themselves to ensure that stored usernames and passwords (which are all @@ -116,7 +116,7 @@ and `headers` of the HTTP request that was made to your inbox. ### Inbox -Your project's [inbox](/documentation/build/inbox) contains all of the messages +Your project's [inbox](../build/inbox.md) contains all of the messages that have been sent to your project. Messages are stored payloads or data (e.g., an incoming SMS, a submitted CommCare form) that were sent via HTTP post to your inbox. diff --git a/versioned_docs/version-legacy/instant-openhie.md b/versioned_docs/version-legacy/instant-openhie.md index 72b510e8536..587464e4b45 100644 --- a/versioned_docs/version-legacy/instant-openhie.md +++ b/versioned_docs/version-legacy/instant-openhie.md @@ -2,11 +2,13 @@ title: Instant OpenHIE --- -:::caution Microservice and devtools are being replaced by Lightning +:::caution Microservice and devtools have been replaced by Lightning Please note that OpenFn/microservice and OpenFn/devtools are being deprecated -and replaced by OpenFn/lightning, When Lighting is released, it may be used -within Instant OpenHIE (instead of microservice) as an OpenHIE-compliant workflow engine that can interface with the OpenHIE Interoperability Layer ([learn more](/documentation/about-lightning#standards-and-compliance-matter)). +and replaced by OpenFn/lightning. Lightning may be used within Instant OpenHIE +(instead of microservice) as an OpenHIE-compliant workflow engine that can +interface with the OpenHIE Interoperability Layer +([learn more](./about-lightning.md#standards-and-compliance-matter)). ::: @@ -291,35 +293,35 @@ These two methods are detailed below: [openhiestack]: https://openhim.readthedocs.io/en/latest/implementations/openhie.html [openhiearchitecture]: https://wiki.ohie.org/pages/viewpage.action?pageId=8454157 [openhim]: http://openhim.org/ -[jobs]: /documentation/build/jobs/ +[jobs]: ./build/jobs.md [mediators]: http://openhim.org/mediator-library/ [demorepo]: https://github.com/OpenFn/instant-demo -[openfnmicroservice]: /documentation/microservice/home/ +[openfnmicroservice]: ./microservice/home.md [digitalsquare]: https://digitalsquare.org/ [fhir]: https://fhir.org/ [hapifhir]: https://hapifhir.io/ [commcare]: https://www.commcarehq.org/ [kobo]: https://www.kobotoolbox.org/ -[projects]: /documentation/build/example-build/ +[projects]: ./build/example-build.md [projectyaml]: https://github.com/OpenFn/microservice/blob/main/project.yaml.example -[triggers]: /documentation/build/triggers/ +[triggers]: ./build/triggers.md [commcaresample]: https://github.com/OpenFn/instant-demo/blob/main/fixtures/commcare_sample.json [kobosample]: https://github.com/OpenFn/instant-demo/blob/main/fixtures/koboCaseRegistration.json [patientspec]: https://www.hl7.org/fhir/patient-example.json.html [encouterspec]: https://www.hl7.org/fhir/encounter-example.json.html [openhiecomm]: https://ohie.org/tag/community/ [jembi]: https://www.jembi.org/ -[cred]: /documentation/build/credentials/ -[trig]: /documentation/build/triggers/ -[devtools]: /documentation/devtools/home/#configure-an-openfn-project +[cred]: ./build/credentials.md +[trig]: ./build/triggers.md +[devtools]: ./devtools/home.md#configure-an-openfn-project [testfile]: https://github.com/OpenFn/instant-demo/blob/main/test.js [instantdemo]: https://github.com/OpenFn/instant-demo [samplecred]: https://github.com/OpenFn/instant-demo/blob/main/openfn/docker/config/project.yaml#L165-L167 [openfncli]: https://github.com/OpenFn/devtools/#configure-an-openfn-project [demoexpr]: https://github.com/OpenFn/instant-demo/tree/main/expressions -[jobexpr]: /documentation/build/jobs/#a-basic-expression +[jobexpr]: ./build/jobs.md#a-basic-expression [sampleyaml]: https://github.com/OpenFn/instant-demo/blob/main/openfn/docker/config/project.yaml [curl]: https://curl.se/ -[studio]: /documentation/jobs/job-studio/ +[studio]: ./jobs/job-studio.md [examplejobs]: https://openfn.org/projects/p5pqx3/jobs diff --git a/versioned_docs/version-legacy/intro/home.md b/versioned_docs/version-legacy/intro/home.md index e0b21b8da27..0dc361f5f5b 100644 --- a/versioned_docs/version-legacy/intro/home.md +++ b/versioned_docs/version-legacy/intro/home.md @@ -37,7 +37,7 @@ Some OpenFn use cases are: ## Who is it built by? -OpenFn products are built by the [Open Function Group](/documentation/about) and +OpenFn products are built by the [Open Function Group](../about.md) and a growing community of open-source contributors. ## Our products @@ -47,7 +47,7 @@ users the freedom to switch between any and all of the OpenFn products. All OpenFn products, other than the OpenFn iPaaS are part of the free and open-source -[**OpenFn Integration Toolkit**](/documentation/getting-started/integration-toolkit). +[**OpenFn Integration Toolkit**](../getting-started/integration-toolkit.md). This Toolkit is a **Digital Public Good** (a "DPG") recognized in the [DPG Registry](https://digitalpublicgoods.net/registry/) and Digital Square's [Global Goods Guidebook](https://digitalsquare.org/resourcesrepository/global-goods-guidebook). @@ -84,7 +84,7 @@ If you have any questions about our products, please don't hesitate to email ### OpenFn developer tooling -#### [OpenFn/cli](/documentation/cli) +#### [OpenFn/cli](../cli.md) A set of CLI tools for writing & testing expressions, managing OpenFn projects, and developing [adaptors](https://github.com/openfn/adaptors). @@ -94,7 +94,7 @@ and developing [adaptors](https://github.com/openfn/adaptors). You can view the technical documentation and source code for OpenFn's FOSS integration tools and adaptors in their respective repositories at [Github.com/OpenFn](https://github.com/openfn) or see -[Deploy](/documentation/deploy/options) section for an overview of the FOSS +[Deploy](../deploy/options.md) section for an overview of the FOSS options and additional docs. ::: diff --git a/versioned_docs/version-legacy/jobs/editing_locally.md b/versioned_docs/version-legacy/jobs/editing_locally.md index c09eab88858..cd7faeeb33a 100644 --- a/versioned_docs/version-legacy/jobs/editing_locally.md +++ b/versioned_docs/version-legacy/jobs/editing_locally.md @@ -3,10 +3,10 @@ title: Editing jobs locally --- To edit jobs, instead of using the OpenFn -[Job Studio](/documentation/jobs/job-studio) you can also use your favorite text +[Job Studio](./job-studio.md) you can also use your favorite text editor and make changes offline, committing and pushing to GitHub to deploy to your OpenFn using the -[version control feature](/documentation/manage/platform-mgmt/#github-version-control). +[version control feature](../manage/platform-mgmt.md/#github-version-control). First, make sure that version control is set up for your project and the job in question. When that's all done, follow the steps below: @@ -71,4 +71,4 @@ From there, the version control integration will update changed jobs in your OpenFn project and you can test those changes on the platform. Once you're ready to start running jobs and testing your changes _locally_, head -over to the [The CLI](/documentation/cli) docs for guidance. +over to the [The CLI](../cli.md) docs for guidance. diff --git a/versioned_docs/version-legacy/jobs/errors.md b/versioned_docs/version-legacy/jobs/errors.md index 9bf0a9e6dc8..bc88a1a2d1a 100644 --- a/versioned_docs/version-legacy/jobs/errors.md +++ b/versioned_docs/version-legacy/jobs/errors.md @@ -80,9 +80,9 @@ exit code itself couldn't be captured by our application. ## Limits -We've shifted this content to a dedicated [limits](/documentation/jobs/limits) +We've shifted this content to a dedicated [limits](./limits.md) page. -### [NodeVM memory limits](/documentation/jobs/limits#nodevm-memory-limits) +### [NodeVM memory limits](./limits.md#nodevm-memory-limits) -### [Job state limits](/documentation/jobs/limits#job-state-limits) +### [Job state limits](./limits.md#job-state-limits) diff --git a/versioned_docs/version-legacy/jobs/job-design-intro.md b/versioned_docs/version-legacy/jobs/job-design-intro.md index b5a6966dd92..6825cd10991 100644 --- a/versioned_docs/version-legacy/jobs/job-design-intro.md +++ b/versioned_docs/version-legacy/jobs/job-design-intro.md @@ -10,7 +10,7 @@ other words, mapping data elements from one system to the other. Designing a job really just means clearly defining the “rules” for data element mapping. We'll walk through the main steps using Kobo Toolbox as an example -source system and a Postgres database as destination but check out the [integration design](/documentation/design/design-quickstart/) page for more details on data flow diagrams and mappings. +source system and a Postgres database as destination but check out the [integration design](../design/design-quickstart.md) page for more details on data flow diagrams and mappings. Step 1: Map your data flows diff --git a/versioned_docs/version-legacy/jobs/job-studio.md b/versioned_docs/version-legacy/jobs/job-studio.md index ea2a11803f5..79977f3025c 100644 --- a/versioned_docs/version-legacy/jobs/job-studio.md +++ b/versioned_docs/version-legacy/jobs/job-studio.md @@ -3,8 +3,8 @@ title: The OpenFn Job Studio --- The OpenFn Job Studio allows you create and test jobs on the platform with easy -access to documentation of [adaptors](/documentation/build/jobs#adaptors), -matching [messages](/documentation/build/inbox) and real-time logs. +access to documentation of [adaptors](../build/jobs.md#adaptors), +matching [messages](../build/inbox.md) and real-time logs. ```mdx-code-block import ReactPlayer from 'react-player'; diff --git a/versioned_docs/version-legacy/jobs/working_with_branches.md b/versioned_docs/version-legacy/jobs/working_with_branches.md index b2e254a2a5c..c2df368f1ed 100644 --- a/versioned_docs/version-legacy/jobs/working_with_branches.md +++ b/versioned_docs/version-legacy/jobs/working_with_branches.md @@ -2,7 +2,7 @@ title: Working with branches --- -In the [Editing jobs locally](/documentation/jobs/editing_locally) section we +In the [Editing jobs locally](./editing_locally.md) section we walked through the process of creating and adding your changes to the `main` branch of a project. @@ -27,7 +27,7 @@ repo to your local folder. branch. When you start editing your jobs, the changes will be kept on this branch, managed separately from `main`. -2. To test the changes locally, check out the [The CLI](/documentation/cli) +2. To test the changes locally, check out the [The CLI](../cli.md) docs. 3. Just as you've seen when working on `main`, when you're done check which diff --git a/versioned_docs/version-legacy/manage/platform-mgmt.md b/versioned_docs/version-legacy/manage/platform-mgmt.md index f54f8318333..967a97a3d54 100644 --- a/versioned_docs/version-legacy/manage/platform-mgmt.md +++ b/versioned_docs/version-legacy/manage/platform-mgmt.md @@ -39,7 +39,7 @@ steps below: :::info Note that once a job is **switched on**, OpenFn will run it automatically, as -[configured](/documentation/build/jobs). If you do not want a job to be run +[configured](../build/jobs.md). If you do not want a job to be run automatically, by OpenFn, then turn it **off**. ::: @@ -193,21 +193,21 @@ steps** and an **expression editor**. In **Fullscreen mode**, the **four configuration steps** appear as regular fields, without a wizard. The **four configuration steps** include giving the job a name, defining what -[triggers](/documentation/build/triggers) its execution, selecting an +[triggers](../build/triggers.md) its execution, selecting an [adaptor](/adaptors), and providing -[authentication](/documentation/build/credentials) details. +[authentication](../build/credentials.md) details. The **expression editor** is the area where you write your -[job expression](/documentation/jobs/#composing-job-expressions). Fill-in +[job expression](../build/jobs.md/#composing-job-expressions). Fill-in all the details, and click on the **Save** icon in the top-right corner to save your job's configuration changes. #### Inspecting job's initial state This feature allows you to view the -[initial state](/documentation/jobs/state/#initial-state) of a selected job. +[initial state](../jobs/state.md/#initial-state) of a selected job. Note that this feature is currently only available for -[message-triggered jobs](/documentation/build/triggers#message-filter-triggers). +[message-triggered jobs](../build/triggers.md#message-filter-triggers). To view or inspect a job's initial state, click the expression pane splitter and drag to the right. After dragging, you will see a `json tree` representation of @@ -219,7 +219,7 @@ as data path for the job's expression. #### Accessing inline adaptor documentation For a selected adaptor, OpenFn allows you to view documentation and code -examples for each [adaptor operation](/documentation/jobs/operations). +examples for each [adaptor operation](../jobs/operations.md). To view adaptor documentation, click on the `documentation icon`(first icon) on the top-right corner of the `Expression Pane`. @@ -289,7 +289,7 @@ trigger, follow the steps below: - Find the trigger you would like to **edit**. - On the bottom-left corner of the trigger card, click on **Edit**. - See details about types of triggers and other editing options - [here](/documentation/build/triggers). + [here](../build/triggers.md). ### Deleting a trigger @@ -321,7 +321,7 @@ To create a new trigger, follow the steps below: - Clicking the **+** button will open **New Trigger Form** for you to enter the details for your new trigger. - See details about types of triggers and other editing options - [here](/documentation/build/triggers). + [here](../build/triggers.md). ## Credentials @@ -382,7 +382,7 @@ given credential, follow the steps below: - Find the credential you would like to **edit**. - On the bottom-left corner of the credential card, click on **Edit**. - See details about types of credentials and other editing options - [here](/documentation/build/credentials). + [here](../build/credentials.md). ### Transferring credential ownership @@ -469,7 +469,7 @@ To create a new credential, follow the steps below: - After choosing the type of credential, OpenFn will open the **New Credential Form** for you to enter the details. - See details about types of credentials and other editing options - [here](/documentation/build/credentials). + [here](../build/credentials.md). ## Activity @@ -490,7 +490,7 @@ began and ended. > performing multiple actions in a destination system or if they are fetching > lots of data from a REST api at the start of a migration. They will appear as > red if they have failed. In the case of failure, refer to our -> [Troubleshooting](/documentation/manage/troubleshooting-tips-on-platform) +> [Troubleshooting](../manage/troubleshooting-tips-on-platform.md) > section below. ### Filter runs in the Activity view @@ -806,12 +806,12 @@ finished working on the first. #### Exporting Project Config - OpenFn allows you to run your project as a - [Microservice](/documentation/microservice/home/) . + [Microservice](../microservice/home.md) . - There are two options for exporting the project config used in OpenFn Microservice. Exporting as `project.yaml` will provide you with a `YAML` file that can be used to run this project with - [OpenFn/engine](/documentation/microservice/home/), - [OpenFn/microservice](/documentation/microservice/home/), or for use in + [OpenFn/engine](../microservice/home.md), + [OpenFn/microservice](../microservice/home.md), or for use in another OpenFn/platform space. - Exporting as `microservice.zip` will prepare a `ZIP` file with `openfn/microservice:latest` (from hub.docker.com) and a your `YAML` file @@ -1023,7 +1023,7 @@ empty file) to Github, `autodeploy` is on, and that file is linked to an OpenFn job, you will **erase your existing job** and you may not be able to retrieve it. ⚠️ -For this reason, and because [**OpenFn/cli**](/documentation/cli) provides a +For this reason, and because [**OpenFn/cli**](../cli.md) provides a free, open-source, offline testing environment, it's recommended to create your jobs using a Github repo and test them on your own machine _before_ linking them to a project on OpenFn. diff --git a/versioned_docs/version-legacy/manage/troubleshooting-tips-on-platform.md b/versioned_docs/version-legacy/manage/troubleshooting-tips-on-platform.md index c9ba921ac21..635c7309bbd 100644 --- a/versioned_docs/version-legacy/manage/troubleshooting-tips-on-platform.md +++ b/versioned_docs/version-legacy/manage/troubleshooting-tips-on-platform.md @@ -12,7 +12,7 @@ Currently, this section is specific to **OpenFn/platform**. ## Runs One of the most helpful pages for troubleshooting on OpenFn platform is the -[Activity History](/documentation/getting-started/terminology/#activity-history). +[Activity History](../getting-started/terminology.md#activity-history). This pages provides a list of all of the runs executed in a project and always marks any failed runs red or yellow. Project administrators can troubleshoot errors by clicking into the run to review the run details. Keep reading for all @@ -23,7 +23,7 @@ troubleshooting! Every run will have an exit code. The exit code is a way for OpenFn to classify the run status and can help you troubleshoot errors. Learn more about OpenFn -exit codes and what each one means [here](/documentation/jobs/errors). +exit codes and what each one means [here](../jobs/errors.md). ### The time it took for the job to fail @@ -95,22 +95,22 @@ Leverage the various search functionalities in OpenFn to find the right messages and runs to support your troubleshooting. You can search in the Inbox, Activity History, and Search Console. -1. **[Inbox](/documentation/manage/platform-mgmt/#inbox)** - The inbox contains +1. **[Inbox](../manage/platform-mgmt.md#inbox)** - The inbox contains all the messages that have been sent to your project. Search your project inbox for messages that contain a specific body text. You can also filter these messages by date, run status and trigger. You can even use filtering to see all the messages whose last run failed, so you can get to troubleshooting! Learn more about inbox filtering - [here](/documentation/manage/platform-mgmt/#inbox). + [here](../manage/platform-mgmt.md#inbox). -2. **[Activity history](/documentation/getting-started/terminology/#activity-history)** - +2. **[Activity history](../getting-started/terminology.md#activity-history)** - As discussed above, the activity history records all runs for the current project. It has similar search and filtering capabilities as the inbox except it doesn't require valid JSON in the search box. Use the search in activity history instead of inbox when you want to search **_run logs_** instead of messages. -3. **[Search console](/documentation/manage/platform-mgmt/#search-console)** - +3. **[Search console](./platform-mgmt.md#search-console)** - The search console will search in both message bodies **_and_** run logs for any string is entered! @@ -123,7 +123,7 @@ leverage **bulk reprocessing** in the OpenFn inbox and activity history to reprocess all messages in the current filtered query. This means OpenFn will rerun all of those transactions in the order they were received. Learn more about bulk reprocessing -[here](/documentation/manage/platform-mgmt/#bulk-reprocess-messages). +[here](./platform-mgmt.md#bulk-reprocess-messages). Sometimes you'll have so many messages with failed runs that it will be virtually impossible to open each one and inspect the run logs. In this case, diff --git a/versioned_docs/version-legacy/openfn-roadmap.md b/versioned_docs/version-legacy/openfn-roadmap.md index c5a53b6f4e1..5a7e3b45125 100644 --- a/versioned_docs/version-legacy/openfn-roadmap.md +++ b/versioned_docs/version-legacy/openfn-roadmap.md @@ -20,7 +20,7 @@ product suite. This includes OpenFn/`Lightning`, `Adaptors`, and `Docs`. OpenFn/Lightning is the fully open-source workflow automation platform at the core of the OpenFn Digital Public Good (learn more about the product -[here](/documentation/about-lightning)). +[here](./about-lightning.md)). | **Feature** | **`Status`** | **Target Timeline** | **Related Links** | **Description** | | ---------------------------------------------------------------------- | ------------ | ------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | @@ -53,7 +53,7 @@ workflow engine, enable automated workflows that cut across digital systems. | **Feature** | **`Status`** | **Target Timeline** | **Related Links** | **Description** | | ------------------------------------------------------------------------------------------------- | ------------ | ------------------- | ------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| 1. Enhancements to [`FHIR`](http://www.hl7.org/fhir/) & [`OpenHIM`](http://openhim.org/) adaptors | Not Started | Q3 2023 | See existing adaptors for [FHIR](/adaptors/packages/fhir-docs) and [OpenHIM](/adaptors/packages/openhim-docs) | To rebuild the existing 2021 [OpenFn Instant-OpenHIE reference demo](/documentation/instant-openhie) to highlight the exchange of data between existing non-FHIR digital health tools and a HAPI FHIR server. (OpenFn Lightning is OpenHIE-compliant and can be used as a workflow engine for the OpenHIE Interoperability layer - [learn more here](/documentation/about-lightning#standards-and-compliance-matter).) We also want to demonstrate data exchange between existing non-FHIR digital health tools and key components of Google’s [Open Health Stack](https://developers.google.com/open-health-stack) and [Cloud Healthcare API](https://cloud.google.com/healthcare-api/docs/concepts/fhir) | +| 1. Enhancements to [`FHIR`](http://www.hl7.org/fhir/) & [`OpenHIM`](http://openhim.org/) adaptors | Not Started | Q3 2023 | See existing adaptors for [FHIR](/adaptors/packages/fhir-docs) and [OpenHIM](/adaptors/packages/openhim-docs) | To rebuild the existing 2021 [OpenFn Instant-OpenHIE reference demo](./instant-openhie.md) to highlight the exchange of data between existing non-FHIR digital health tools and a HAPI FHIR server. (OpenFn Lightning is OpenHIE-compliant and can be used as a workflow engine for the OpenHIE Interoperability layer - [learn more here](./about-lightning.md#standards-and-compliance-matter).) We also want to demonstrate data exchange between existing non-FHIR digital health tools and key components of Google’s [Open Health Stack](https://developers.google.com/open-health-stack) and [Cloud Healthcare API](https://cloud.google.com/healthcare-api/docs/concepts/fhir) | | 2. Add "magic" functions to existing, in-demand adaptors | Not started | Q3 2023 | [Issue 243](https://github.com/OpenFn/adaptors/issues/243) | Add functions, dynamic lists, and shortcuts to fast-track workflow configuration for key adaptors including HTTP, [DHIS2](https://dhis2.org/), [CommCare](https://www.dimagi.com/commcare/), & [OpenMRS](https://openmrs.org/) | | 3. New [`OpenMRS`](https://openmrs.org/) adaptor version | Not started | Q3 2023 | [See existing adaptor docs](/adaptors/packages/openmrs-readme) | To ensure compliance with OpenMRS v3 | | 4. Enhancements to the [`OCL`](https://openconceptlab.org/) adaptor | Not started | Q3 2023 | [See existing adaptor docs](/adaptors/packages/ocl-readme) | To ensure that mappings stored in OCLs can be more easily access and processed as inputs in OpenFn/Lightning workflows | @@ -62,7 +62,7 @@ workflow engine, enable automated workflows that cut across digital systems. | **Feature** | **`Status`** | **Target Timeline** | **Related Links** | **Description** | | ----------------------------------------------------------- | ------------ | ------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| 1. OpenFn and the [OpenHIE](https://ohie.org/) architecture | Planned | Q2 2023 | [See current docs](/documentation/about-lightning#standards-and-compliance-matter) | New page dedicated to how OpenHIE aligns with OpenHIE architecture; expansion of the existing small section on standards | +| 1. OpenFn and the [OpenHIE](https://ohie.org/) architecture | Planned | Q2 2023 | [See current docs](./about-lightning.md#standards-and-compliance-matter) | New page dedicated to how OpenHIE aligns with OpenHIE architecture; expansion of the existing small section on standards | | 2. New Lightning User Guidance | Not started | Q3 2023 | To be hosted on docs.openfn.org | New documentation, videos, and other user guidance on how to use OpenFn/Lightning and how to migrate existing OpenFn/platform projects to Lightning (the new OpenFn "v2") | | 3. Template [FHIR](http://www.hl7.org/fhir/) Workflows | Planned | Q3 2023 | To be hosted on demo.openfn.org | OpenFn can already help achieve FHIR compliance, but we will build and document reference/template workflows to demonstrate how OpenFn/Lightning can automate data exchange, registration, and/or reporting workflows between non-FHIR data systems and FHIR APIs. | | 4. Template Alerting Workflows | Not started | Q4 2023 | [See OpenHIE docs](https://guides.ohie.org/arch-spec/introduction/alerting-sending-reminders-or-information); to be hosted on demo.openfn.org | To demonstrate how OpenFn can facilitate one-way communication to a client or provider listed in the HIE (from the OpenHIE standard spec) | @@ -74,4 +74,4 @@ workflow engine, enable automated workflows that cut across digital systems. Post on the OpenFn Community at [community.openfn.org](https://community.openfn.org), or consider contributing to the OpenFn software, adaptors, or documentation (learn more in the -[Contributing section](/documentation/writing-code)). +[Contributing section](./writing-code.md)). diff --git a/versioned_docs/version-legacy/portability-versions.md b/versioned_docs/version-legacy/portability-versions.md index f824370d7ba..bc5192cfb98 100644 --- a/versioned_docs/version-legacy/portability-versions.md +++ b/versioned_docs/version-legacy/portability-versions.md @@ -10,7 +10,7 @@ be used to import or export projects between OpenFn/platform and OpenFn/engine. The portability specification v4 defines how entire projects (groups of workflows with their associated triggers, credentials and jobs) can be represented as code. This specification has been written for -[Lightning](/documentation/getting-started/integration-toolkit/#lightning-coming-soon), +[Lightning](./getting-started/integration-toolkit.md/#lightning-coming-soon), the fully open source webb app which extends the OpenFn DPG. It aims to (a) improve developer experience, allowing them to build and test workflows locally; (b) enable version control and an audit trail of project changes; and (c) enable diff --git a/versioned_docs/version-legacy/release-notes.md b/versioned_docs/version-legacy/release-notes.md index b2bb0ef2bd6..4339db7d4b2 100644 --- a/versioned_docs/version-legacy/release-notes.md +++ b/versioned_docs/version-legacy/release-notes.md @@ -35,7 +35,7 @@ New features: - **Exclusion filters:** Users can now specify message filter triggers to _exclude_ messages matching a certain signature via the same matching rules as the standard _inclusion_ filter. Read more in the - [docs](/documentation/build/triggers#message-filter-triggers) + [docs](./build/triggers.md#message-filter-triggers) ## Version 1.90.30 (2021-03-31) From e0511fd879062a398ab2db92af75cc3ec05eef88 Mon Sep 17 00:00:00 2001 From: Taylor Downs Date: Tue, 13 Feb 2024 07:42:16 +0000 Subject: [PATCH 7/8] final links --- adaptors/intro.mdx | 14 +++++++++----- docs/build-for-developers/jobs.md | 2 +- docs/build/steps/steps.md | 9 ++++----- docs/build/workflows.md | 6 +++--- docs/contribute/openfn-roadmap.md | 17 +++++++++-------- 5 files changed, 26 insertions(+), 22 deletions(-) diff --git a/adaptors/intro.mdx b/adaptors/intro.mdx index 26e64d73f84..ad4b3b5d746 100644 --- a/adaptors/intro.mdx +++ b/adaptors/intro.mdx @@ -15,11 +15,14 @@ First, it's important to note that OpenFn can connect to _any system_ via HTTP, but our community has also built dozens of "adaptors" to save time & money while connecting to most commonly used digital public goods and key ICT4D systems. -You can even run web scraping or browser automation tools with OpenFn. See the +You can even run web scraping or browser automation tools with OpenFn. It's +almost like a universal translator... 🖖 + + + ## What's an adaptor? @@ -132,7 +135,8 @@ Most of our adaptors are also available on ![Adaptors list in npm](/img/adaptor_npm.png) -#### Install on platform via npm + + ## Building and extending adaptors diff --git a/docs/build-for-developers/jobs.md b/docs/build-for-developers/jobs.md index bc6f8891bd7..eb9ea945b36 100644 --- a/docs/build-for-developers/jobs.md +++ b/docs/build-for-developers/jobs.md @@ -2,7 +2,7 @@ title: Jobs --- -Jobs define the specific series of "operations" (think: tasks or database actions) to be performed in an individual Workflow Step. See the [Steps section](/docs/build/steps/steps) for detailed documentation and tips for [writing Job expressions](/docs/build/steps/jobs). +Jobs define the specific series of "operations" (think: tasks or database actions) to be performed in an individual Workflow Step. See the [Steps section](../build/steps/steps.md) for detailed documentation and tips for [writing Job expressions](../build/steps/jobs.md). :::note diff --git a/docs/build/steps/steps.md b/docs/build/steps/steps.md index 953a738ad48..506de66354d 100644 --- a/docs/build/steps/steps.md +++ b/docs/build/steps/steps.md @@ -34,8 +34,8 @@ A Step includes these key components: Writing Jobs to add custom logic for business or data transformation rules typically requires basic knowledge of JavaScript. See the -[Job-writing docs](/documentation/build/workflows) for a detailed -overview and the [Library Examples](/adaptors/library) for sample code. +[Job-writing docs](/documentation/build/workflows) for a detailed overview and +the [Library Examples](/adaptors/library) for sample code. ::: @@ -133,6 +133,5 @@ want this and to avoid the risk of accidental upgrades on live Workflows. Click the code button `` displayed on the configuration panel to write or edit a Job expression to define the "rules" or the specific tasks to be -completed by your Step. See the pages on -[the Inspector](/docs/build/steps/step-editor) and -[writing Jobs](/docs/build/steps/jobs) to learn more. +completed by your Step. See the pages on [the Inspector](./step-editor.md) and +[writing Jobs](./jobs.md) to learn more. diff --git a/docs/build/workflows.md b/docs/build/workflows.md index eb686eab224..7600ad12747 100644 --- a/docs/build/workflows.md +++ b/docs/build/workflows.md @@ -13,9 +13,9 @@ To create a new Workflow in your Project: 1. Go to the `Workflows` page. 2. Click `Create new workflow` button. 3. Give your Workflow a descriptive `Name` (e.g., `Register patients`, `Refer cases`, `Monthly payroll`). -4. Choose your [Trigger](/documentation/build/triggers) -5. Edit your first [Step](/documentation/build/steps/steps) -6. Modify the [Path Condition](/documentation/build/paths), if needed, to define _when_ the Workflow should proceed to the next Step. +4. Choose your [Trigger](../build/triggers.md) +5. Edit your first [Step](../build/steps/steps.md) +6. Modify the [Path Condition](../build/paths.md), if needed, to define _when_ the Workflow should proceed to the next Step. 7. Configure more Steps as needed Check out the video overview below to learn how to create a Workflow. diff --git a/docs/contribute/openfn-roadmap.md b/docs/contribute/openfn-roadmap.md index a1ce42be97b..815c3236670 100644 --- a/docs/contribute/openfn-roadmap.md +++ b/docs/contribute/openfn-roadmap.md @@ -5,7 +5,8 @@ sidebar_label: OpenFn Roadmap :::warning Under construction -This docs page is under construction. Check back later for the complete docs, or check out the Docs Version "Platform (v1)". +This docs page is under construction. Check back later for the complete docs, or +check out the Docs Version "Platform (v1)". ::: @@ -57,18 +58,18 @@ databases, and even raw data files, enabling interoperability with any information system ([read more](/adaptors/)). Adaptors, alongside OpenFn's workflow engine, enable automated workflows that cut across digital systems. -| **Feature** | **`Status`** | **Target Timeline** | **Related Links** | **Description** | -| ------------------------------------------------------------------------------------------------- | ------------ | ------------------- | ------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| **Feature** | **`Status`** | **Target Timeline** | **Related Links** | **Description** | +| ------------------------------------------------------------------------------------------------- | ------------ | ------------------- | ------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 1. Enhancements to [`FHIR`](http://www.hl7.org/fhir/) & [`OpenHIM`](http://openhim.org/) adaptors | Not Started | Q3 2023 | See existing adaptors for [FHIR](/adaptors/packages/fhir-docs) and [OpenHIM](/adaptors/packages/openhim-docs) | To rebuild the existing 2021 [OpenFn Instant-OpenHIE reference demo](/documentation/get-started/standards#openhie-standard-architecture) to highlight the exchange of data between existing non-FHIR digital health tools and a HAPI FHIR server. (OpenFn Lightning is OpenHIE-compliant and can be used as a workflow engine for the OpenHIE Interoperability layer - [learn more here](/documentation#openfn-v2-lightning-#standards-and-compliance-matter).) We also want to demonstrate data exchange between existing non-FHIR digital health tools and key components of Google’s [Open Health Stack](https://developers.google.com/open-health-stack) and [Cloud Healthcare API](https://cloud.google.com/healthcare-api/docs/concepts/fhir) | -| 2. Add "magic" functions to existing, in-demand adaptors | Not started | Q3 2023 | [Issue 243](https://github.com/OpenFn/adaptors/issues/243) | Add functions, dynamic lists, and shortcuts to fast-track workflow configuration for key adaptors including HTTP, [DHIS2](https://dhis2.org/), [CommCare](https://www.dimagi.com/commcare/), & [OpenMRS](https://openmrs.org/) | -| 3. New [`OpenMRS`](https://openmrs.org/) adaptor version | Not started | Q3 2023 | [See existing adaptor docs](/adaptors/packages/openmrs-readme) | To ensure compliance with OpenMRS v3 | -| 4. Enhancements to the [`OCL`](https://openconceptlab.org/) adaptor | Not started | Q3 2023 | [See existing adaptor docs](/adaptors/packages/ocl-readme) | To ensure that mappings stored in OCLs can be more easily access and processed as inputs in OpenFn/Lightning workflows | +| 2. Add "magic" functions to existing, in-demand adaptors | Not started | Q3 2023 | [Issue 243](https://github.com/OpenFn/adaptors/issues/243) | Add functions, dynamic lists, and shortcuts to fast-track workflow configuration for key adaptors including HTTP, [DHIS2](https://dhis2.org/), [CommCare](https://www.dimagi.com/commcare/), & [OpenMRS](https://openmrs.org/) | +| 3. New [`OpenMRS`](https://openmrs.org/) adaptor version | Not started | Q3 2023 | [See existing adaptor docs](/adaptors/packages/openmrs-readme) | To ensure compliance with OpenMRS v3 | +| 4. Enhancements to the [`OCL`](https://openconceptlab.org/) adaptor | Not started | Q3 2023 | [See existing adaptor docs](/adaptors/packages/ocl-readme) | To ensure that mappings stored in OCLs can be more easily access and processed as inputs in OpenFn/Lightning workflows | ### Docs Roadmap | **Feature** | **`Status`** | **Target Timeline** | **Related Links** | **Description** | | ----------------------------------------------------------- | ------------ | ------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| 1. OpenFn and the [OpenHIE](https://ohie.org/) architecture | Planned | Q2 2023 | [See current docs](/documentation#openfn-v2-lightning-#standards-and-compliance-matter) | New page dedicated to how OpenHIE aligns with OpenHIE architecture; expansion of the existing small section on standards | +| 1. OpenFn and the [OpenHIE](https://ohie.org/) architecture | Planned | Q2 2023 | [See current docs](/documentation#openfn-v2-lightning-#standards-and-compliance-matter) | New page dedicated to how OpenHIE aligns with OpenHIE architecture; expansion of the existing small section on standards | | 2. New Lightning User Guidance | Not started | Q3 2023 | To be hosted on docs.openfn.org | New documentation, videos, and other user guidance on how to use OpenFn/Lightning and how to migrate existing OpenFn/platform projects to Lightning (the new OpenFn "v2") | | 3. Template [FHIR](http://www.hl7.org/fhir/) Workflows | Planned | Q3 2023 | To be hosted on demo.openfn.org | OpenFn can already help achieve FHIR compliance, but we will build and document reference/template workflows to demonstrate how OpenFn/Lightning can automate data exchange, registration, and/or reporting workflows between non-FHIR data systems and FHIR APIs. | | 4. Template Alerting Workflows | Not started | Q4 2023 | [See OpenHIE docs](https://guides.ohie.org/arch-spec/introduction/alerting-sending-reminders-or-information); to be hosted on demo.openfn.org | To demonstrate how OpenFn can facilitate one-way communication to a client or provider listed in the HIE (from the OpenHIE standard spec) | @@ -80,4 +81,4 @@ workflow engine, enable automated workflows that cut across digital systems. Post on the OpenFn Community at [community.openfn.org](https://community.openfn.org), or consider contributing to the OpenFn software, adaptors, or documentation (learn more in the -[Contributing section](/documentation/writing-code)). +[Contributing section](./writing-code.md)). From 66a4c16ebecb13e01dcef4d7448d7c048e779561 Mon Sep 17 00:00:00 2001 From: Taylor Downs Date: Tue, 13 Feb 2024 07:43:26 +0000 Subject: [PATCH 8/8] capitalize --- sidebars-main.js | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sidebars-main.js b/sidebars-main.js index 3d33cb103ec..79041260aa3 100644 --- a/sidebars-main.js +++ b/sidebars-main.js @@ -2,7 +2,7 @@ module.exports = { docs: [ { type: 'category', - label: 'Get started', + label: 'Get Started', items: [ 'get-started/home', 'get-started/terminology', @@ -32,7 +32,7 @@ module.exports = { }, { type: 'category', - label: 'Build & manage Workflows', + label: 'Build & Manage Workflows', items: [ 'build/workflows', 'build/triggers',