Skip to content

Commit

Permalink
Merge pull request #888 from mandy-chessell/code2024
Browse files Browse the repository at this point in the history
Fix formatting and typos in release notes
  • Loading branch information
mandy-chessell committed Jan 24, 2024
2 parents 6894933 + 6f887f4 commit 16eed3d
Show file tree
Hide file tree
Showing 15 changed files with 65 additions and 52 deletions.
8 changes: 4 additions & 4 deletions site/docs/concepts/governance-action-process-intro.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,7 +2,7 @@
<!-- Copyright Contributors to the ODPi Egeria project. -->


A *governance action process* is a predefined sequence of [engine actions](/concepts/engine-action that are coordinated by the [Governance Engine OMAS](/services/omas/governance-engine/overview).
A *governance action process* is a predefined sequence of [engine actions](/concepts/engine-action) that are coordinated by the [Governance Engine OMAS](/services/omas/governance-engine/overview).

The steps in a governance action process are defined by linked [governance action process steps](/concepts/governance-action-process-step) stored in the open metadata ecosystem. Each governance action process step provides the specification of the governance action to run. The links between them show which [guards](/concepts/guard) cause the next step to be chosen and hence, the governance action to run.

Expand Down Expand Up @@ -31,20 +31,20 @@ Example 2 shows an [open discovery service](/concepts/open-discovery-service) am
## Capturing lineage for a governance action process

The [engine actions](/concepts/engine-action generated when a governance action process runs provide a complete audit trace of the governance services that ran and their results. The [Governance Action Open Lineage Integration Connector](/connectors/integration/governance-action-open-lineage-integration-connector) is able to monitor the operation of the governance actions and produce [OpenLineage events](/features/lineage-management/overview/#the-openlineage-standard) to provide operational lineage for governance action processes. Egeria is also able to [capture these events](/connectors/#capturing-and-publishing-lineage) (along with OpenLineage events from other technologies) for later analysis.
The [engine actions](/concepts/engine-action) generated when a governance action process runs provide a complete audit trace of the governance services that ran and their results. The [Governance Action Open Lineage Integration Connector](/connectors/integration/governance-action-open-lineage-integration-connector) is able to monitor the operation of the governance actions and produce [OpenLineage events](/features/lineage-management/overview/#the-openlineage-standard) to provide operational lineage for governance action processes. Egeria is also able to [capture these events](/connectors/#capturing-and-publishing-lineage) (along with OpenLineage events from other technologies) for later analysis.

## Governance Action Process Lifecycle

The diagram below shows a governance action process assembly tool taking in information from a [governance engine pack](/concepts/governance-engine-pack) to build a governance action process flow. This is shared with the open metadata ecosystem either through direct called to the [Governance Engine OMAS](/services/omas/governance-engone/overview) or via a [open metadata archive](/concepts/open-metadata-archive) (possibly the archive that holds the governance engine definition.

Once the definition of the governance action process is available, an instance of the process can be started, either by a [watchdog governance action service](/concepts/governance-action-service) or through a direct call to the Governance Engine OMAS. Whichever mechanism is used, it results in the Governance Engine OMAS using the definition to choreograph the creation of [engine action](/concepts/engine-action entities that drive the execution of the governance services in the [Engine Host](/concepts/engine-host).
Once the definition of the governance action process is available, an instance of the process can be started, either by a [watchdog governance action service](/concepts/governance-action-service) or through a direct call to the Governance Engine OMAS. Whichever mechanism is used, it results in the Governance Engine OMAS using the definition to choreograph the creation of [engine action](/concepts/engine-action) entities that drive the execution of the governance services in the [Engine Host](/concepts/engine-host).

![Lifecycle](/concepts/governance-action-process-lifecycle.svg)


!!! education "Further information"
- The [0462 Governance Action Processes](/types/4/0462-Governance-Action-Processes) model shows how the governance action process flow is built out of [governance action process steps](/concepts/governance-action-process-step).
- Governance action processes may be created using the [Governance Engine OMAS](/services/omas/governance-engine/overview) API.
- The [Open Metadata Engine Services (OMES)](/services/omes) provide the mechanisms that support the different types of [governance engines](/concepts/governance-engine). These engines run the [governance services](/concepts/governance-service) that execute the [engine actions](/concepts/engine-action defined by the governance action process.
- The [Open Metadata Engine Services (OMES)](/services/omes) provide the mechanisms that support the different types of [governance engines](/concepts/governance-engine). These engines run the [governance services](/concepts/governance-service) that execute the [engine actions](/concepts/engine-action) defined by the governance action process.


5 changes: 4 additions & 1 deletion site/docs/concepts/governance-action-type.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,6 +4,9 @@

# Governance Action Type

Governance Action Type has been renamed to [Governance Action Process Step](/concepts/governance-action-process-step)
A *Governance Action Type* is a template that describes a call to a [governance engine](/concepts/governance-engine). Through the [open governance service](/services/gaf-metadata-management), it is possible to use the governance action type to initiate the specified call to the governance engine. The result is the creation of an [engine action](/concepts/engine-action) that controls the execution of the call.

!!! education "Properties of a governance action type"
The open metadata type definition for the governance action type is in model [0462 Governance Action Processes](/types/4/0462-Governance-Action-Processes).

--8<-- "snippets/abbr.md"
2 changes: 1 addition & 1 deletion site/docs/concepts/guard.md
Original file line number Diff line number Diff line change
Expand Up @@ -6,7 +6,7 @@

Guards are labels that are created by [governance services](/concepts/governance-service)
and are used by the [Governance Engine OMAS](/services/omas/governance-engine/overview) to
determine which [engine action](/concepts/engine-action to run next.
determine which [engine action](/concepts/engine-action) to run next.


--8<-- "snippets/abbr.md"
2 changes: 1 addition & 1 deletion site/docs/concepts/index.md
Original file line number Diff line number Diff line change
Expand Up @@ -156,7 +156,7 @@
- [Glossary](/practices/common-data-definitions/anatomy-of-a-glossary)
- [Glossary Category](/practices/common-data-definitions/anatomy-of-a-glossary/#glossary-categories)
- [Glossary Term](/practices/common-data-definitions/anatomy-of-a-glossary/#inside-a-glossary-term)
- [Governance Action](/concepts/engine-action)
- [Governance Action](/concepts/governance-action)
- [Governance Action Engine](/concepts/governance-action-engine)
- [Governance Action OMES](/service/omes/governance-action/overview)
- [Governance Action Framework (GAF)](/frameworks/gaf/overview)
Expand Down
2 changes: 1 addition & 1 deletion site/docs/features/discovery-and-stewardship/overview.md
Original file line number Diff line number Diff line change
Expand Up @@ -55,7 +55,7 @@ Schema extraction uses the [schema analysis annotation](/types/6/0615-Schema-Ext

![Open discovery schema extraction](/guides/developer/open-discovery-services/open-discovery-schema-extraction.svg)

The schema of the data in the digital resource is defined in a *SchemaType* linked from the digital resource's asset using the *AssetSchemaType* relationship. This may be established before the open discovery service runs, or may be derived by an [engine action](/concepts/engine-action once the open discovery service has run.
The schema of the data in the digital resource is defined in a *SchemaType* linked from the digital resource's asset using the *AssetSchemaType* relationship. This may be established before the open discovery service runs, or may be derived by an [engine action](/concepts/engine-action) once the open discovery service has run.

If the schema is defined, the open discovery service that creates the data fields may maintain relationships between the schema and the data fields:

Expand Down
2 changes: 1 addition & 1 deletion site/docs/features/lineage-management/overview.md
Original file line number Diff line number Diff line change
Expand Up @@ -257,7 +257,7 @@ The numbers on the diagram refer to the notes below.

3. The [OpenLineage Event Receiver](/connectors/integration/open-lineage-event-receiver-integration-connector) integration connector is receiving OpenLineage events from the Kafka topic. It passes them to the Lineage Integrator OMIS's context manager via its own context.

4. The [Governance Action OpenLineage](/connectors/integration/governance-action-open-lineage-integration-connector) integration connector has registered a listener to receive events about the [engine actions](/concepts/engine-action that are being processed in the open metadata ecosystem.
4. The [Governance Action OpenLineage](/connectors/integration/governance-action-open-lineage-integration-connector) integration connector has registered a listener to receive events about the [engine actions](/concepts/engine-action) that are being processed in the open metadata ecosystem.

5. The Governance Action OpenLineage integration connector creates OpenLineage events to represent the processing by the governance actions and passes them to the Lineage Integrator OMIS's context manager via its own context.

Expand Down
2 changes: 1 addition & 1 deletion site/docs/features/synchronized-access-control/overview.md
Original file line number Diff line number Diff line change
Expand Up @@ -16,7 +16,7 @@ There are many factors that influence who should have access to a digital servic

Egeria enables all of this information to be assembled and linked together at multiple levels - for example a database column may be linked to a glossary term called employee-salary that is in turn classified as sensitive personal information (SPI).

Security managers, such as Apache Ranger, however just needs to know that the column is SPI. So [engine actions](/concepts/engine-action convert this complex model into something much more operationally-focused in the form of *security tags*. The security tags attached to the schemas are all that needs to be distributed to the security managers.
Security managers, such as Apache Ranger, however just needs to know that the column is SPI. So [engine actions](/concepts/engine-action) convert this complex model into something much more operationally-focused in the form of *security tags*. The security tags attached to the schemas are all that needs to be distributed to the security managers.

## Representing security tags

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -31,33 +31,35 @@ The server type name should be set to something that describes the OMAG Server's

If you have no specific value to set the server type name to, we recommend that you set the server type name to null. This will cause the server start up process will derive a standard server type name based on the rest of the configuration for the server.

!!! post "POST - setBasicServerProperties"
```
{{platformURLRoot}}/open-metadata/admin-services/users/{{adminUserId}}/servers/{{serverName}}/server-properties"
```
The request body contains the properties to set.

| Property | Description |
|--------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| *localServerDescription* | Description for the server. This is useful information for the administrator to understand the role of the server. The default value is `null`. |
| *organizationName* | Descriptive name for the organization that owns the local server/repository. This is useful when the open metadata repository cluster consists of metadata servers from different organizations, or different departments of an enterprise. The default value is `null`. |
| *localServerURL* | The *platformURLRoot* for the platform where this server is to run. For example `https://localhost:9443`. It is used if the server connects to a [cohort](/concepts/cohort-member). |
| *localServerUserId* | UserId to use for server-initiated REST calls. The default is `OMAGServer`. |
| *localServerPassword* | Password to use for server-initiated REST calls. The default is `null`. This means that only the userId is sent in the HTTP header. |
| *maxPageSize* | The maximum page size that can be set on requests to the server. The default value is `1000`. A value of zero means unlimited page size. Although supported, the zero value is not recommended because it provides no protection from a large request denial of service attack. |

For example:

```json
{
"localServerDescription" : "This server supports the governance teams",
"organizationName" : "Coco Pharmaceuticals",
"localServerURL" : "https://localhost:9443",
"localServerUserId" : "cocomds2npa",
"localServerPassword" : "secret",
"maxPageSize" : 600
}
```
???+ post "POST - setBasicServerProperties"
```
{{platformURLRoot}}/open-metadata/admin-services/users/{{adminUserId}}/servers/{{serverName}}/server-properties"
```
The request body contains the properties to set.

| Property | Description |
|--------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| *localServerDescription* | Description for the server. This is useful information for the administrator to understand the role of the server. The default value is `null`. |
| *organizationName* | Descriptive name for the organization that owns the local server/repository. This is useful when the open metadata repository cluster consists of metadata servers from different organizations, or different departments of an enterprise. The default value is `null`. |
| *localServerURL* | The *platformURLRoot* for the platform where this server is to run. For example `https://localhost:9443`. It is used if the server connects to a [cohort](/concepts/cohort-member). |
| *localServerUserId* | UserId to use for server-initiated REST calls. The default is `OMAGServer`. |
| *localServerPassword* | Password to use for server-initiated REST calls. The default is `null`. This means that only the userId is sent in the HTTP header. |
| *maxPageSize* | The maximum page size that can be set on requests to the server. The default value is `1000`. A value of zero means unlimited page size. Although supported, the zero value is not recommended because it provides no protection from a large request denial of service attack. |

For example:

```json
{
"localServerDescription" : "This server supports the governance teams",
"organizationName" : "Coco Pharmaceuticals",
"localServerURL" : "https://localhost:9443",
"localServerUserId" : "cocomds2npa",
"localServerPassword" : "secret",
"maxPageSize" : 600
}
```

Alternatively, you can set these properties one at a time.

### Set server description

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -106,7 +106,7 @@ The connector provider for your governance action service provides the factory m

Below is the implementation of the connector provider for the [Move Copy File Provisioning Governance Action Service](/connectors/governance-action/move-copy-file-provisioning-governance-action-service). This is a highly configurable governance action service that can be instructed to move, copy or delete a file, and has different styles of lineage it can create. The action it performs is supplied in the governance request type. The source file and destination folder can be supplied either through the request parameters or as action targets. There are two guards: "provisioning-complete" for success and "provisioning-failed" if something went wrong.

The methods of the connector provider enables a tool that is configuring [engine actions](/concepts/engine-action or [governance action processes](/concepts/governance-action-process) to query the capabilities of the corresponding governance action service.
The methods of the connector provider enables a tool that is configuring [engine actions](/concepts/engine-action) or [governance action processes](/concepts/governance-action-process) to query the capabilities of the corresponding governance action service.

```java
public class MoveCopyFileGovernanceActionProvider extends GovernanceActionServiceProviderBase
Expand Down
Loading

0 comments on commit 16eed3d

Please sign in to comment.