|
1 |
| -# Welcome to @cap-js/change-tracking |
2 | 1 |
|
3 |
| -## About this project |
| 2 | +The `@cap-js/change-tracking` package is a [CDS plugin](https://cap.cloud.sap/docs/node.js/cds-plugins#cds-plugin-packages) providing out-of-the box support for automatic capturing, storing, and viewing of the change records of modeled entities. |
4 | 3 |
|
5 |
| -`@cap-js/change-tracking` is a CDS plugin providing out-of-the box support for automatic capturing, storing, and viewing of the change records of modeled entities. |
| 4 | +### Table of Contents |
6 | 5 |
|
7 |
| -Documentation can be found at [cap.cloud.sap](https://cap.cloud.sap/docs). |
| 6 | +- [Setup](#setup) |
| 7 | +- [Usage](#usage) |
| 8 | + - [Add `@changelog` Annotations](#add-changelog-annotations) |
| 9 | + - [Human-readable Types and Fields](#human-readable-types-and-fields) |
| 10 | + - [Human-readable IDs](#human-readable-ids) |
| 11 | + - [Human-readable Values](#human-readable-values) |
| 12 | + - [Test-drive locally](#test-drive-locally) |
| 13 | + - [Change History View](#change-history-view) |
| 14 | + - [Customizations](#customizations) |
| 15 | +- [Contributing](#contributing) |
| 16 | + - [Code of Conduct](#code-of-conduct) |
| 17 | +- [Licensing](#licensing) |
8 | 18 |
|
9 |
| -## Requirements |
10 | 19 |
|
11 |
| -See [Getting Started](https://cap.cloud.sap/docs/get-started) on how to jumpstart your development and grow as you go with SAP Cloud Application Programming Model. |
12 | 20 |
|
13 |
| -## Support, Feedback, Contributing |
| 21 | +## Setup |
| 22 | + |
| 23 | +To enable change tracking, simply add this self-configuring plugin package to your project: |
| 24 | + |
| 25 | +```sh |
| 26 | +npm add @cap-js/change-tracking |
| 27 | +``` |
| 28 | + |
| 29 | + |
| 30 | + |
| 31 | +## Usage |
| 32 | + |
| 33 | +In this guide, we use the [Incidents Management reference sample app](https://github.com/cap-js/incidents-app) as the base to add change tracking to. |
| 34 | + |
| 35 | +### Add `@changelog` Annotations |
| 36 | + |
| 37 | +All we need to do is to identify what should be change-tracked by annotating respective entities and elements in our model with the `@changelog` annotation. Following the [best practice of separation of concerns](https://cap.cloud.sap/docs/guides/domain-modeling#separation-of-concerns), we do so in a separate file _srv/change-tracking.cds_: |
| 38 | + |
| 39 | +```cds |
| 40 | +using { ProcessorService } from './processor-service'; |
| 41 | +
|
| 42 | +annotate ProcessorService.Incidents { |
| 43 | + customer @changelog: [customer.name]; |
| 44 | + title @changelog; |
| 45 | + status @changelog; |
| 46 | +} |
| 47 | +
|
| 48 | +annotate ProcessorService.Conversations with @changelog: [author, timestamp] { |
| 49 | + message @changelog @Common.Label: 'Message'; |
| 50 | +} |
| 51 | +``` |
| 52 | + |
| 53 | +The minimal annotation we require for change tracking is `@changelog` on elements, as for the elements `title` and `status` in the sample snippet above. |
| 54 | + |
| 55 | +Additional identifiers or labels can be added to obtain more *human-readable* change records as described below. |
| 56 | + |
| 57 | + |
| 58 | +#### Human-readable Types and Fields |
| 59 | + |
| 60 | +By default the implementation looks up *Object Type* names or *Field* namesfrom respective `@title` or `@Common.Label` annotations, and applies i18n lookups. If no such annotations are given, the technical names of the respective CDS definitions are displayed. |
| 61 | + |
| 62 | +For example, without the `@title` annotation, changes to conversation entries would show up with the technical entity name: |
| 63 | + |
| 64 | +<img width="1300" alt="change-history-type" src="_assets/changes-type-wbox.png"> |
| 65 | + |
| 66 | +With an annotation, and possible i18n translations like so: |
| 67 | + |
| 68 | +```cds |
| 69 | +annotate Conversations with @title: 'Conversations'; |
| 70 | +``` |
| 71 | + |
| 72 | +We get a human-readable display for *Object Type*: |
| 73 | + |
| 74 | +<img width="1300" alt="change-history-type-hr" src="_assets/changes-type-hr-wbox.png"> |
| 75 | + |
| 76 | + |
| 77 | +#### Human-readable IDs |
| 78 | + |
| 79 | +The changelog annotations for *Object ID* are defined at entity level. |
| 80 | + |
| 81 | +These are already human-readable by default, unless the `@changelog` definition cannot be uniquely mapped such as types `enum` or `Association`. |
| 82 | + |
| 83 | +For example, having a `@changelog` annotation without any additional identifiers, changes to conversation entries would show up as simple entity IDs: |
| 84 | + |
| 85 | +```cds |
| 86 | +annotate ProcessorService.Conversations { |
| 87 | +``` |
| 88 | +<img width="1300" alt="change-history-id" src="_assets/changes-id-wbox.png"> |
| 89 | + |
| 90 | +However, this is not advisable as we cannot easily distinguish between changes. It is more appropriate to annotate as follows: |
| 91 | + |
| 92 | +```cds |
| 93 | +annotate ProcessorService.Conversations with @changelog: [author, timestamp] { |
| 94 | +``` |
| 95 | +<img width="1300" alt="change-history-id-hr" src="_assets/changes-id-hr-wbox.png"> |
| 96 | + |
| 97 | +Expanding the changelog annotation by additional identifiers `[author, timestamp]`, we can now better identify the `message` change events by their respective author and timestamp. |
| 98 | + |
| 99 | + |
| 100 | +#### Human-readable Values |
| 101 | + |
| 102 | +The changelog annotations for *New Value* and *Old Value* are defined at element level. |
| 103 | + |
| 104 | +They are already human-readable by default, unless the `@changelog` definition cannot be uniquely mapped such as types `enum` or `Association`. |
| 105 | + |
| 106 | +For example, having a `@changelog` annotation without any additional identifiers, changes to incident customer would show up as UUIDs: |
| 107 | + |
| 108 | +```cds |
| 109 | + customer @changelog; |
| 110 | +``` |
| 111 | + |
| 112 | +<img width="1300" alt="change-history-value" src="_assets/changes-value-wbox.png"> |
| 113 | + |
| 114 | +Hence, here it is essential to add a unique identifier to obtain human-readable value columns: |
| 115 | + |
| 116 | +```cds |
| 117 | + customer @changelog: [customer.name]; |
| 118 | +``` |
| 119 | + |
| 120 | +<img width="1300" alt="change-history-value-hr" src="_assets/changes-value-hr-wbox.png"> |
| 121 | + |
| 122 | + |
| 123 | +### Test-drive locally |
| 124 | + |
| 125 | +With the steps above, we have successfully set up change tracking for our reference application. Let's see that in action. |
| 126 | + |
| 127 | +1. **Start the server**: |
| 128 | + ```sh |
| 129 | + cds watch |
| 130 | + ``` |
| 131 | +2. **Make a change** on your change-tracked elements. This change will automatically be persisted in the database table (`sap.changelog.ChangeLog`) and made available in a pre-defined view, namely the [Change History view](#change-history-view) for your convenience. |
| 132 | + |
| 133 | +### Change History View |
| 134 | + |
| 135 | +<img width="1300" alt="change-history" src="_assets/changes.png"> |
| 136 | + |
| 137 | +If you have a Fiori Element application, the CDS plugin automatically provides and generates a view `sap.changelog.ChangeView`, the facet of which is automatically added to the Fiori Object Page of your change-tracked entities/elements. In the UI, this corresponds to the *Change History* table which serves to help you to view and search the stored change records of your modeled entities. |
| 138 | + |
| 139 | +### Customizations |
| 140 | + |
| 141 | +The view can be easily adapted and configured to your own needs by simply changing or extending it. For example, let's assume we only want to show the first 5 columns in equal spacing, we would extend `srv/change-tracking.cds` as follows: |
| 142 | + |
| 143 | +```cds |
| 144 | +using from '@cap-js/change-tracking'; |
| 145 | +
|
| 146 | +annotate sap.changelog.ChangeView with @( |
| 147 | + UI.LineItem : [ |
| 148 | + { Value: modification, @HTML5.CssDefaults: { width:'20%' }}, |
| 149 | + { Value: createdAt, @HTML5.CssDefaults: { width:'20%' }}, |
| 150 | + { Value: createdBy, @HTML5.CssDefaults: { width:'20%' }}, |
| 151 | + { Value: entity, @HTML5.CssDefaults: { width:'20%' }}, |
| 152 | + { Value: objectID, @HTML5.CssDefaults: { width:'20%' }} |
| 153 | + ] |
| 154 | +); |
| 155 | +``` |
| 156 | + |
| 157 | +In the UI, the *Change History* table now contains 4 equally-spaced columns with the desired properties: |
| 158 | + |
| 159 | +<img width="1300" alt="change-history-custom" src="_assets/changes-custom.png"> |
| 160 | + |
| 161 | +For more information and examples on adding Fiori Annotations, see [Adding SAP Fiori Annotations](https://cap.cloud.sap/docs/advanced/fiori#fiori-annotations). |
| 162 | + |
| 163 | + |
| 164 | +## Contributing |
14 | 165 |
|
15 | 166 | This project is open to feature requests/suggestions, bug reports etc. via [GitHub issues](https://github.com/cap-js/change-tracking/issues). Contribution and feedback are encouraged and always welcome. For more information about how to contribute, the project structure, as well as additional contribution information, see our [Contribution Guidelines](CONTRIBUTING.md).
|
16 | 167 |
|
17 |
| -## Code of Conduct |
| 168 | + |
| 169 | +### Code of Conduct |
18 | 170 |
|
19 | 171 | We as members, contributors, and leaders pledge to make participation in our community a harassment-free experience for everyone. By participating in this project, you agree to abide by its [Code of Conduct](CODE_OF_CONDUCT.md) at all times.
|
20 | 172 |
|
| 173 | + |
21 | 174 | ## Licensing
|
22 | 175 |
|
23 | 176 | Copyright 2023 SAP SE or an SAP affiliate company and contributors. Please see our [LICENSE](LICENSE) for copyright and license information. Detailed information including third-party components and their licensing/copyright information is available [via the REUSE tool](https://api.reuse.software/info/github.com/cap-js/change-tracking).
|
0 commit comments