Updates to docs excluding event driven content (#228)

* Updates to docs excluding event driven content

* Updates for PR #228

---------

Co-authored-by: Israel Slobodkin 
Co-authored-by: chullybun

Author: israels

Diff for: samples/MyEf.Hr/README.md

@@ -59,40 +59,7 @@ Endpoint | Description
 `DELETE /reviews/id` | Delete an existing review.
 `GET /employee/id/reviews` | Gets all review(s) for the employee (with paging support).
 
-</br>
-
-## Solution skeleton
-
-This solution should be created using the solution [template](../../templates/Beef.Template.Solution/README.md) capability, following the getting started [guide](../../docs/Sample-SqlServer-EF-GettingStarted.md).
-
-The following four commands should be invoked to create the solution structure. Start in a folder where the solution should reside. To simplify the ongoing copy and paste activities within this sample it is _highly recommended_ that the `MyEf.Hr` naming convention below is used.
-
-```
-dotnet new install beef.template.solution --nuget-source https://api.nuget.org/v3/index.json
-mkdir MyEf.Hr
-cd MyEf.Hr
-dotnet new beef --company MyEf --appname Hr --datasource SqlServer
-```
-
-The following solution structure will have been generated. Open `MyEf.Hr.sln` in Visual Studio.
-
-```
-└── MyEf.Hr               # Solution that references all underlying projects
-  └── Testing
-    └── MyEf.Hr.Test      # Unit and intra-integration tests
-  └── Tools
-    └── MyEf.Hr.CodeGen   # Entity and Reference Data code generation console
-    └── MyEf.Hr.Database  # Database code generation console
-  └── MyEf.Hr.Api         # API end-point and operations
-  └── MyEf.Hr.Business    # Core business logic components
-  └── MyEf.Hr.Common      # Common / shared components
-```
-
-_Note:_ Code generation should **not** be performed before updating the corresponding YAML files as described in the next sections. Otherwise, extraneous files will be generated that will then need to be manually removed.
-
-Also, any files that start with `Person` (being the demonstration entity) should be removed (deleted) from their respective projects as they are encountered. This then represents the baseline to build up the solution from.
-
-</br>
+<br/>
 
 ## Railway-oriented programming
 
@@ -102,20 +69,21 @@ The [`Result`](https://github.com/Avanade/CoreEx/blob/main/src/CoreEx/Results/Re
 
 <br/>
 
-## Implementation steps
+## Core Implementation steps
 
 As described earlier, this sample will walk through the implementation in a number of logical steps:
 
-1. [Employee DB](./docs/Employee-DB.md) - creates the `Employee` database table and related entity framework capabilities.
-2. [Employee API](./docs/Employee-Api.md) - creates the `Employee` entities, API and related data access logic.
-3. [Employee Test](./docs/Employee-Test.md) - creates the `Employee` end-to-end integration tests to validate the API and database functionality.
-4. [Employee Search](./docs/Employee-Search.md) - adds the `Employee` search capability and tests.
-5. [Employee Terminate](./docs/Employee-Terminate.md) - adds the `Employee` termination capability and tests.
-6. [Employee Performance Review](./docs/Performance-Review.md) - adds the employee `PerformanceReview` capability end-to-end, from the the database, through the APIs and corresponding testing.
+1. [Solution Skeleton](./docs/1-Solution-Skeleton.md) - start by creating a VS solution from Beef template
+2. [Employee DB](./docs/2-Employee-DB.md) - creates the `Employee` database table and related entity framework capabilities.
+3. [Employee API](./docs/3-Employee-Api.md) - creates the `Employee` entities, API and related data access logic.
+4. [Employee Test](./docs/4-Employee-Test.md) - creates the `Employee` end-to-end integration tests to validate the API and database functionality.
+5. [Employee Search](./docs/5-Employee-Search.md) - adds the `Employee` search capability and tests.
+6. [Employee Terminate](./docs/6-Employee-Terminate.md) - adds the `Employee` termination capability and tests.
+7. [Employee Performance Review](./docs/7-Performance-Review.md) - adds the employee `PerformanceReview` capability end-to-end, from the the database, through the APIs and corresponding testing.
 
 <br/>
 
-## Event driven architecture implementation
+## Event Driven Architecture implementation
 
 The implementation so far has created the API capabilities to perform operations on the data as originally defined in the [scope](#Scope). This section can be [skipped](#Conclusion) where the related Event-driven architecture capabilities are not required.
 
@@ -147,9 +115,9 @@ The _HR_ and _Security_ domains are completely decoupled from each other; in tha
 
 This _EDA_ sample will walk through the implementation in a number of logical steps (these describe the integration of the _CoreEx_ capabilities to enable) to achieve the end-to-end Employee's User Account deactivation:
 
-7. [Transactional Outbox](./docs/Transactional-Outbox.md) - enqueue events into the database.
-8. [Service Bus Publish](./docs/Service-Bus-Publish.md) - dequeue events (relay) from database publishing to Azure Service Bus.
-9. [Service Bus Subscribe](./docs/Service-Bus-Subscribe.md) - simulate an additional domain subscribing to an event (from Azure Service Bus).
+8. [Transactional Outbox](./docs/8-Transactional-Outbox.md) - enqueue events into the database.
+9. [Service Bus Publish](./docs/9-Service-Bus-Publish.md) - dequeue events (relay) from database publishing to Azure Service Bus.
+10. [Service Bus Subscribe](./docs/10-Service-Bus-Subscribe.md) - simulate an additional domain subscribing to an event (from Azure Service Bus).
 
 <br/>
 

Diff for: samples/MyEf.Hr/docs/1-Solution-Skeleton.md

@@ -0,0 +1,48 @@
+# Step 1 - Solution Skeleton
+
+The starting point of any solution built on top of Beef is to first create the Visual Studio solution skeleton, utilizing the solution [template](../../templates/Beef.Template.Solution/README.md).
+
+*To simplify the ongoing copy and paste activities within this sample it is highly recommended that the `MyEf.Hr` naming convention below is used.*
+
+Open a development terminal, navigate to an appropriate parent folder and execute the following four commands to create the solution structure.
+
+```
+dotnet new install beef.template.solution --nuget-source https://api.nuget.org/v3/index.json
+mkdir MyEf.Hr
+cd MyEf.Hr
+dotnet new beef --company MyEf --appname Hr --datasource SqlServer
+```
+
+The following solution structure will have been generated. Execute `.\MyEf.Hr.sln` to open in Visual Studio.
+
+```
+└── MyEf.Hr               # Solution that references all underlying projects
+  └── Testing
+    └── MyEf.Hr.Test      # Unit and intra-integration tests
+  └── Tools
+    └── MyEf.Hr.CodeGen   # Entity and Reference Data code generation console
+    └── MyEf.Hr.Database  # Database code generation console
+  └── MyEf.Hr.Api         # API end-point and operations
+  └── MyEf.Hr.Business    # Core business logic components
+  └── MyEf.Hr.Common      # Common / shared components
+```
+<br/>
+
+## Important Notes
+Code generation should **not** be performed before updating the corresponding YAML files as described in the next sections. Otherwise, extraneous files will be generated that will then need to be manually removed.
+
+Also, any files that start with `Person` (being the demonstration entity) should be removed (deleted) from their respective projects as they are encountered. This then represents the baseline to build up the solution from.
+
+<br/>
+
+## Next Step
+
+Next, we can begin creating the [employee DB](./2-Employee-DB.md) and related database objects required for the sample.<br/>
+
+<br/>
+
+## Appendix
+
+For more detail on the solution template see the following docs:
+* [Solution Template](../../../templates/Beef.Template.Solution/README.md)
+* [Getting started guide](../../../docs/Sample-SqlServer-EF-GettingStarted.md).

Diff for: samples/MyEf.Hr/docs/Service-Bus-Subscribe.md renamed to samples/MyEf.Hr/docs/10-Service-Bus-Subscribe.md

@@ -1,4 +1,4 @@
-# Step 9 - Service Bus Subscribe
+# Step 10 - Service Bus Subscribe
 
 At a high-level this represents the subscribing of events/messages from Azure Service Bus to meet the stated requirements of when an Employee is _terminated_ that the Employee's User Account will be automatically _deactivated_ within OKTA.
 
@@ -445,8 +445,12 @@ Now that all the moving parts have been developed and configured an end-to-end i
 
 <br/>
 
-## Conclusion
+## Verify
 
 The new _Security_ domain that performs a [Service Bus Subscribe](./Service-Bus-Subscribe.md) of the _Termination_ related events and proxies [Okta]() (as our identity solution) automatically _Deactivating_ the Employee's account is complete.
 
+<br/>
+
+## Next Step
+
 Next we will [wrap up](./../README.md#Conclusion) the sample - we are done!    

Diff for: samples/MyEf.Hr/docs/Employee-DB.md renamed to samples/MyEf.Hr/docs/2-Employee-DB.md

@@ -1,10 +1,16 @@
-# Step 1 - Employee DB
+# Step 2 - Employee DB
 
 This will walk through the process of creating the required tables, and entity framework capabilities, etc. needed for the `Employee` within a Microsoft SQL Server database. All of this work will occur within the context of the `MyEf.Hr.Database` project.
 
 The [`Beef.Database.SqlServer`](../../../tools/Beef.Database.SqlServer) and [`DbEx`](https://github.com/Avanade/dbex) provide the capabilities that will be leveraged. The underlying [documentation](https://github.com/Avanade/dbex#readme) describes these capabilities and the database approach in greater detail.
 
-_Note:_ Any time that command line execution is requested, this should be performed from the base `MyEf.Hr.Database` folder. To see all supported command line options execute `dotnet run -- --help`.
+<br/>
+
+## Terminal
+
+The database codegen and DbEx commands will run from a command-line interface. In preparation for the steps below, open a new terminal/command-prompt and navigate to the `MyEf.Hr.Database` base folder directory
+
+_Note: To see all supported command line options execute `dotnet run -- --help`._
 
 <br/>
 
@@ -45,6 +51,7 @@ Create the `Hr` schema using the database tooling. The following command will cr
 dotnet run script schema Hr
 ```
 
+<br/>
 
 ## Create Employee table
 
@@ -137,16 +144,19 @@ dotnet run script refdata Hr USState
 
 Now that the Reference Data tables exist they will need to be populated. It is recommended that where possible that the Production environment values are specified (as these are intended to be deployed to all environments).
 
-These values (database rows) are specified using YAML. For brevity in this document, copy the data for the above tables **only** (for now) from [`RefData.yaml`](../MyEf.Hr.Database/Data/RefData.yaml) replacing the contents of the prefilled `RefData.yaml` within the `My.Hr.Database/Data` folder. Finally, remove the `PerformanceOutcome` lines at the end of the file.
+These values (database rows) are specified using YAML. For brevity in this document we will grab the data we need from [`RefData.yaml`](../MyEf.Hr.Database/Data/RefData.yaml). Take the contents of this file, copy and replace the contents of the prefilled `RefData.yaml` within the `My.Hr.Database/Data` folder. Finally, remove the `PerformanceOutcome` lines at the end of the file (we are not creating or populating this table for now).
 
-_Note:_ The format and hierarchy for the YAML, is: Schema, Table, Row. For reference data tables where only `Code: Text` is provided, this is treated as a special case shorthand to update those two columns accordingly (the other columns will be updated automatically). The `$` prefix for a table indicates a `merge` versus an `insert` (default).
+_Note: The format and hierarchy for the YAML, is: Schema, Table, Row. For reference data tables where only `Code: Text` is provided, this is treated as a special case shorthand to update those two columns accordingly (the other columns will be updated automatically). The `$` prefix for a table indicates a `merge` versus an `insert` (default)._
 
 ``` yaml
 Hr:
   - $Gender:
     - F: Female
     - M: Male
     - N: Not specified
+  - $TerminationReason:
+    - RE: Resigned
+    ...
   ...
 ```
 
@@ -156,7 +166,7 @@ Hr:
 
 To support the requirement to query the Reference Data values from the database we will use Entity Framework (EF) to simplify. The Reference Data table configuration will drive the EF .NET (C#) model code-generation via the `efModel: true` attribute. 
 
-Remove all existing configuration from `database.beef-5.yaml` and replace. Each table configuration is referencing the underlying table and schema, then requesting an EF model is created for all related columns found within the database. _Beef_ will query the database to infer the columns during code-generation to ensure it "understands" the latest configuration.
+Remove all existing configuration from `database.beef-5.yaml` and replace with the contents below. Each table configuration is referencing the underlying table and schema, then requesting an EF model is created for all related columns found within the database. _Beef_ will query the database to infer the columns during code-generation to ensure it "understands" the latest configuration.
 
 ``` yaml
 # Configuring the code-generation global settings
@@ -234,19 +244,46 @@ dotnet run codegen
 dotnet run database
 ```
 
-This should create migrations script files with names similar as follows (as well as a number of other SQL and .NET related artefacts).
+<br/>
+
+## Verify
+
+At this stage we now have a working database ready for the consuming API logic to be added. The required database tables exist, the Reference Data data has been loaded, the required stored procedures and user-defined type (UDT) for the Event outbox have been generated and added to the database. The .NET (C#) Entity Framework models have been generated and added to the `My.Hr.Business` project, including the requisite event outbox enqueue/dequeue capabilities. 
+
+To verify, confirm you have the below set of sql migration scripts:
 
 ```
 └── Migrations
-  └── 20210430-170605-create-01-create-outbox-schema.sql
-  └── 20210430-170605-create-01-create-outbox-eventoutbox-table.sql
-  └── 20210430-170605-create-01-create-outbox-eventoutboxdata-table.sql
+  └── <date>-<number>-create-hr-schema.sql
+  └── <date>-<number>-create-hr-employee-table.sql
+  └── <date>-<number>-create-hr-emergencycontact-table.sql
+  └── <date>-<number>-create-hr-gender-refdata-table.sql
+  └── <date>-<number>-create-hr-terminationreason-refdata-table.sql
+  └── <date>-<number>-create-hr-relationshiptype-refdata-table.sql
+  └── <date>-<number>-create-hr-usstate-refdata-table.sql
+  └── <date>-<number>-01-create-outbox-schema.sql
+  └── <date>-<number>-02-create-outbox-eventoutbox-table.sql
+  └── <date>-<number>-03-create-outbox-eventoutboxdata-table.sql
 ```
 
-<br/>
+Confirm also, the following DB and tables have been created (utilizing a DB tool such as Azure Data Explorer or SSMS):
+```
+└── Local
+  └── Databases
+    └── MyEf.Hr
+      └── Tables
+        └── Hr.EmergencyContact
+        └── Hr.Employee
+        └── Hr.Gender
+        └── Hr.RelationshipType
+        └── Hr.TerminationReason
+        └── Hr.USState
+        └── Outbox.EventOutbox
+        └── Outbox.EventOutboxData
+```
 
-## Conclusion
+<br/>
 
-At this stage we now have a working database ready for the consuming API logic to be added. The required database tables exist, the Reference Data data has been loaded, the required stored procedures and user-defined type (UDT) for the Event outbox have been generated and added to the database. The .NET (C#) Entity Framework models have been generated and added to the `My.Hr.Business` project, including the requisite event outbox enqueue/dequeue capabilities. 
+## Next Step
 
-Next we need to create the [employee API](./Employee-Api.md) endpoint to perform the desired CRUD operations.
+Next, we need to create the [employee API](./3-Employee-Api.md) endpoint to perform the desired CRUD operations.