ENDOC-379 Create documentation for the PDA Plugin #360
Conversation
| implementing a set of interfaces on the server side. The backend is a | ||
| Spring Boot microservice that provides a pluggable interface allowing | ||
| for the injection of any underlying process or automation toolkit. The | ||
| layer via pre-developed Entando integration, or by |
There was a problem hiding this comment.
I don't know if I should comment about this, especially at this point, but I'm not sure what this means.
There was a problem hiding this comment.
which part :P @nshaw can you break it down for us?
my tenuous understanding is that the UX is comprised of generic MFEs that customers can tailor either using entando specific integration that entando offers, or by tuning interfaces on the server. the backend is also flexible, and the customer can choose the processes and toolkits to be used.
There was a problem hiding this comment.
Yep, confusing. Let's replace " Customers drive the UX layer via pre-developed Entando integration, or by implementing a set of interfaces on the server side." with something like "The UX layer can serve data via the included Entando integration adapter, or by implementing a set of interfaces on the server side." Maybe a little better...
| Process Driven Apps (PDA) plugin. The initial section addresses the | ||
| business functionality and user-facing micro frontends. The second | ||
| section covers the architecture and points of extension for the PDA | ||
| plugin. The third section supplies a detailed technical overview of how to |
There was a problem hiding this comment.
i think if we go with the model we discussed yesterday a bulleted list would be a great way to set the stage for an overview :)
| user. In the default implementation the visible tasks are limited to a | ||
| single process instance. At configuration time the application designer | ||
| The Task List MFE provides the user with a list of visible tasks that are | ||
| either assigned to or potentially ownable by that user. In the default implementation, the visible tasks are limited to a |
There was a problem hiding this comment.
i struggled with that too... i kept "ownable" in case there's a distinction between the two, but ownable is awkward. and keeps triggering my autocorrect. @nshaw?
There was a problem hiding this comment.
@Lyd1aCla1r3 I think "either assigned to or could be claimed by that user." is more accurate. Not sure it's right for other BPM implementations but it works for PAM.
| @@ -522,31 +453,33 @@ above would look like this: | |||
| // note that property's fields are not mentioned - defaulting them to 12 columns in are that is available to them | |||
There was a problem hiding this comment.
'12 columns in are that'-- unsure what is meant here
There was a problem hiding this comment.
LOL good catch - i didn't even read this somehow?? absolutely no clue what this comment addresses or how to interpret it. @nshaw
There was a problem hiding this comment.
@Lyd1aCla1r3 your edit looks good. A lot of modern UX scaffolding divides the page into 12 columns.
| rowsMax: 4 | ||
| As Material UI components are used for field templates, there might be a need to pass some Material UI options into the field. This can be done by adding the `muiProps` object to `ui:options`. | ||
|
|
||
| For example, if you would like to make the down payment field resizable, you can add `multiline: true` to the `muiProps` option. If you want to make the field to take up multiple rows by default, add the fields `rows` and `rowsMax`. The latter limits how many rows can be added until the scroll bar is shown. |
There was a problem hiding this comment.
'the field take up multiple'
There was a problem hiding this comment.
yikes! pretty sure that's what i meant and never finished editing :| good catch
| since it doesn't have a database. All data available on the API is retrieved | ||
| from the BPM engine. After bundle installation, it will be deployed as a | ||
| microservice in the Kubernetes infrastructure and an Ingress will be created to | ||
| The PDA API is a Spring Boot application that communicates with the Entando engine, and engine data is made available in a Rest API. Subject to deployment configuration, the PDA API interacts with Keycloak to validate the token, and with the sidecar to retrieve the connection and sensitive data. Instead of calling specific engine classes directly, the application calls the abstractions defined in the PDA Core library. |
There was a problem hiding this comment.
"BPM engine, and BPM engine data"
| microservice in the Kubernetes infrastructure and an Ingress will be created to | ||
| The PDA API is a Spring Boot application that communicates with the Entando engine, and engine data is made available in a Rest API. Subject to deployment configuration, the PDA API interacts with Keycloak to validate the token, and with the sidecar to retrieve the connection and sensitive data. Instead of calling specific engine classes directly, the application calls the abstractions defined in the PDA Core library. | ||
|
|
||
| Engine implementation is determined at runtime based on the connection details |
There was a problem hiding this comment.
Minor, I would say "The engine implementation"
| The sidecar is another application (docker container) deployed in the same Pod | ||
| as the PDA API. It exposes services to manage connection details, which will be | ||
| stored as secrets in Kubernetes. The PDA API communicates with the sidecar to | ||
| The sidecar is another application (Docker container) deployed in the same Pod |
There was a problem hiding this comment.
I'm not sure how to track it but I think the sidecar has now been removed in 6.3.2. @Lyd1aCla1r3, once you get your local copy working, let's look at it together. If it's actually gone, we can remove all reference to the sidecar in the /next docs.
|
|
||
| ### PAM Implementation | ||
|
|
||
| The PAM implementation posts the documents to the PAM endpoints for | ||
| storage. Future features will include using Entando document storage for | ||
| storing documents and a pluggable document management interface. | ||
| storage. Future features will include the use of Entando document storage and a pluggable document management interface. |
There was a problem hiding this comment.
Let's remove the Future features sentence. I'm aware of no roadmap for it.
|
|
||
| There are no limitations on the stack that could be used to create PDA | ||
| ## Creating a New PDA MFE |
There was a problem hiding this comment.
I think we can remove both sections here - Creating a new PDA MFE and Communication between MFEs, We have tutorials for those with more information, http://localhost:8080/v6.3.2/tutorials/micro-frontends/react.html and http://localhost:8080/v6.3.2/tutorials/micro-frontends/communication.html
|
@Lyd1aCla1r3 I think I caught the questions but let me know if I missed anything. |
| react-jsonschema-form package | ||
| This section will introduce the basic form configuration, but if you would like to learn more, please refer to the `react-jsonshema-form` documentation. | ||
|
|
||
| The themed `JSOform` is created using the `withTheme()` method from the `react-jsonschema-form` package: |
first pass at one of the docs to rework