QESTNET Internal:Developer QESTNET Creating A New Workflow - Revision history

David.brice: UnitsDataConfiguration -> UnitsToDataConfiguration

2016-04-18T08:28:19Z

UnitsDataConfiguration -> UnitsToDataConfiguration

←Older revision		Revision as of 08:28, 18 April 2016
Line 128:		Line 128:
	** Modify GetUnits appropriately		** Modify GetUnits appropriately
	* Add call in UnitMapper.SetupUnits		* Add call in UnitMapper.SetupUnits
	* Add code to ~~UnitsDataConfiguration~~ and UnitsToEntityConfiguration		* Add code to UnitsToDataConfiguration and UnitsToEntityConfiguration
	* The following commit is a good example: https://github.com/spectraqest/qestnet/commit/f78e8112969ada3c21bbb7c700155b28e0a4719f		* The following commit is a good example: https://github.com/spectraqest/qestnet/commit/f78e8112969ada3c21bbb7c700155b28e0a4719f

David.brice: added short bit about grouping workflow buttons

2016-01-19T01:06:53Z

added short bit about grouping workflow buttons

←Older revision		Revision as of 01:06, 19 January 2016
Line 208:		Line 208:
	* Use existing examples to create processes for your Workflow, normally one add and one edit process.		* Use existing examples to create processes for your Workflow, normally one add and one edit process.
	* Some of the fancier code there will put the edit buttons under the Work Order even if the test normally sits underneath a Sample.		* Some of the fancier code there will put the edit buttons under the Work Order even if the test normally sits underneath a Sample.
			** These buttons can be grouped together using certain tags (as of the time of writing, the tags that can be used for this purpose can be found within UpdateWorkflowLinksProcess), e.g. see in the FieldDensityProcessBundle how the tag "field-density" is used as part of the Description that ends up being used in the code to add the button. Field inspections could be similarly grouped using the tag "field-inspection".

John.meegan at 22:46, 21 October 2015

2015-10-21T22:46:13Z

←Older revision		Revision as of 22:46, 21 October 2015
Line 28:		Line 28:
	* Review the specification or standards to understand what needs implementing		* Review the specification or standards to understand what needs implementing
	* Create all required qestlab.qes objects (tests, lists, etc.)		* Create all required qestlab.qes objects (tests, lists, etc.)
	** Here you need to decide if the test should have the "~~SIUnitsBase~~" property (or similar name). It is only valid for tests that '''will not''' be used in QL. More on units later.		** Here you need to decide if the test should have the "StoreSIBaseInDatabase" property (or similar name). It is only valid for tests that '''will not''' be used in QL. More on units later.
	* Make initial database tables, even if they just have the standard fields		* Make initial database tables, even if they just have the standard fields

Line 54:		Line 54:
	* Run '''GenerateDataSchema.ps1'''		* Run '''GenerateDataSchema.ps1'''
	* Build QESTLab.Data project		* Build QESTLab.Data project
	** If you receive errors similar to '' 'Source file "Entities\UserDocument100.cs" could not be found' '' at this point, right click '''EntityGenerator.tt''', select Run Custom Tool, then rebuild QESTLab.Data.		** If you receive errors similar to '' 'Source file "Entities\UserDocument100.cs" could not be found' '' at this point, right click '''EntityGenerator.tt''', select Run Custom Tool, Do the same for '''EntityGenerator.Context''', then rebuild QESTLab.Data.
	* Right click '''QESTLab_Data_Views.tt''' and select Run Custom Tool		* Right click '''QESTLab_Data_Views.tt''' and select Run Custom Tool
	* Build QESTLab.Data project		* Build QESTLab.Data project
Line 104:		Line 104:
	* This is used to map your QESTLab.Entities Entity to the QESTLab.Data Entity.		* This is used to map your QESTLab.Entities Entity to the QESTLab.Data Entity.
	* In the Entity Mappings folder is 3 files		* In the Entity Mappings folder is 3 files
			** Also update the QestEntityContext.cs file, which may be up a folder.
	* Copy the existing style to add your entities in here		* Copy the existing style to add your entities in here
	* Any Entity that uses UOM needs special handling to include a UOM mapper, you will notice properties that have this on the end: ".Include(units[typeof(Torvane).Name])".		* Any Entity that uses UOM needs special handling to include a UOM mapper, you will notice properties that have this on the end: ".Include(units[typeof(Torvane).Name])".
Line 110:		Line 111:
	** Created Entity field names that are different from the database field names		** Created Entity field names that are different from the database field names
	** Created additional properties or methods on the Entity		** Created additional properties or methods on the Entity
			** An example of this is the CaliforniaBearingRatio Entity's mapping, it has a MaximumDryDensity property but this isn't in the database, so this line is in ToEntityConfigurationSource.cs as: .MapProperty(o => o.Ignore(), d => d.MaximumDryDensity)

	Update the Entity Queries:		Update the Entity Queries:
Line 123:		Line 125:
	** Copy the way others are done.		** Copy the way others are done.
	** The main thing to remember is for compatibility with QL screens, we provide a set of defaults for the units for each field in the database. For example, traditionally MDD tests have saved masses in grams so we set grams as the default for each of the mass fields. In contrast to this an SI base test would save these values in kilograms. These defaults are set by logic so you can have different defaults for IP units, different QestIDs, etc.		** The main thing to remember is for compatibility with QL screens, we provide a set of defaults for the units for each field in the database. For example, traditionally MDD tests have saved masses in grams so we set grams as the default for each of the mass fields. In contrast to this an SI base test would save these values in kilograms. These defaults are set by logic so you can have different defaults for IP units, different QestIDs, etc.
	** Implement applicable methods: GetSIBase(), GetMetric(), GetIP(), etc. Each defines what ~~each~~ unit is used for storing in the database. The dictionary that is chosen for a test depends on what units that test stores in its database fields.		** Implement applicable methods: GetSIBase(), GetMetric(), GetIP(), etc. Each defines what unit is used for storing each field in the database. The dictionary that is chosen for a test depends on what units that test stores in its database fields.
	** Modify GetUnits appropriately		** Modify GetUnits appropriately
	* Add call in UnitMapper.SetupUnits		* Add call in UnitMapper.SetupUnits
Line 146:		Line 148:
	** Run RuleSetPerformedBy - Required if you need to work with TestStages or if you need to set the completion status, this applies to most tests. Each test has its own RuleSetPerformedBy that you have to make.		** Run RuleSetPerformedBy - Required if you need to work with TestStages or if you need to set the completion status, this applies to most tests. Each test has its own RuleSetPerformedBy that you have to make.
	** Check loaded endpoint relations - Rules should only run if all the Entities and their relationships have been loaded, otherwise you'll get null pointer exceptions.		** Check loaded endpoint relations - Rules should only run if all the Entities and their relationships have been loaded, otherwise you'll get null pointer exceptions.
	** ~~Propogate~~ delete actions - Because our Entity relationships make a graph not a tree structure, it is difficult to know what should be deleted when a single test is deleted. The rules for a single Entity should ~~propogate~~ a delete to all related Entities where it makes sense.		** Propagate delete actions - Because our Entity relationships make a graph not a tree structure, it is difficult to know what should be deleted when a single test is deleted. The rules for a single Entity should propagate a delete to all related Entities where it makes sense.

	Rules need to run fast which means:		Rules need to run fast which means:
Line 167:		Line 169:
	* In the Workflow Factories folder		* In the Workflow Factories folder
	* Find a good spot, copy an existing example. Some are Fugro-specific these are not usually useful for other customers.		* Find a good spot, copy an existing example. Some are Fugro-specific these are not usually useful for other customers.
	* You can create a separate factory for each Method you want to create, if they all use the same ~~basica~~ Workflow and Entities. See the SteelReinforcingWorkflowFactory for an example. Each Method has its own Guid so the methods can be individually licensed.		* You can create a separate factory for each Method you want to create, if they all use the same basic Workflow and Entities. See the SteelReinforcingWorkflowFactory for an example. Each Method has its own Guid so the methods can be individually licensed.
	* Generate a new GUID attribute for the WorkflowFactory - this is the ID used in licensing the Workflow		* Generate a new GUID attribute for the WorkflowFactory - this is the ID used in licensing the Workflow
	** This can be done in Visual Studio by going to "Tools > Create Guid"		** This can be done in Visual Studio by going to "Tools > Create Guid"
Line 216:		Line 218:
	* The classes must be named ending in "Model"		* The classes must be named ending in "Model"
	* The [DataMember] attribute makes the field visible to QF. Add these to your fields unless you have a good reason not to.		* The [DataMember] attribute makes the field visible to QF. Add these to your fields unless you have a good reason not to.
			* UOM unit fields must use the Reading classes. For example if you are mapping a Mass? from an Entity, you will need to use a MassReading on the Model. Notice that this is not "MassReading?" (nullable type), the MassReading is a class so it can already be null, but the Mass is a C# Struct, so it needs to be made nullable with the "?".

	Containers are used to organise the Workflow into a tree structure, each container can have many sub-containers. These are sent to QF to be displayed in HTML. There are two types of Containers:		Containers are used to organise the Workflow into a tree structure, each container can have many sub-containers. These are sent to QF to be displayed in HTML. There are two types of Containers:
Line 233:		Line 236:
	Create Container Factories:		Create Container Factories:
	* One per model, plus any additional grouping containers. It's good practice to call these grouping containers "workspaces", see the other similar files.		* One per model, plus any additional grouping containers. It's good practice to call these grouping containers "workspaces", see the other similar files.
			* Mapping UOM fields is a bit trickier as readings need to be created with units, precision, and mapped back appropriately. See how other factories do it.


	==QESTField==		==QESTField==
			In order for the Models you've created in QN to correctly appear in QF you must update the Service Reference. This can be done by:
			* Opening the Service References folder in Visual Studio
			* Right-clicking on the existing Service Reference and clicking "Update"
			* This must be done any time you add / remove fields on a Model or add / remove Models themselves.

	In QF, the Workflows are displayed by Views:		In QF, the Workflows are displayed by Views:
	* All views are in the Views folder		* All views are in the Views folder
Line 244:		Line 253:

	If you create a new folder in the Views directory, you need to add it to the "Global.asax" file in the root of the QESTField project. This will be hopefully automated eventually.		If you create a new folder in the Views directory, you need to add it to the "Global.asax" file in the root of the QESTField project. This will be hopefully automated eventually.

			Create Views:
			* Name them the same name as the Model but without the word Model.
			* Copy how the others are done. Change the name of the Model at the top.
			* Create Razor-HTML for each field you need.

John.meegan at 22:32, 21 October 2015

2015-10-21T22:32:28Z

@@ Line 233: / Line 233: @@
 Create Container Factories:
 * One per model, plus any additional grouping containers. It's good practice to call these grouping containers "workspaces", see the other similar files.
+If you create a new folder in the Views directory, you need to add it to the "Global.asax" file in the root of the QESTField project. This will be hopefully automated eventually.

John.meegan at 22:24, 21 October 2015

2015-10-21T22:24:13Z

@@ Line 209: / Line 209: @@
 ===QESTLab.Workflow: Container Factories / QESTLab.Models===
 Models...
 It makes sense to create these together.

John.meegan at 05:27, 21 October 2015

2015-10-21T05:27:27Z

←Older revision		Revision as of 05:27, 21 October 2015
Line 164:		Line 164:

	===QESTLab.Workflow: Workflow Factory===		===QESTLab.Workflow: Workflow Factory===

	Create a new Workflow Factory:		Create a new Workflow Factory:
	* In the Workflow Factories folder		* In the Workflow Factories folder
Line 191:		Line 190:

	Phases use Processes, which are a general way of creating logic and actions for Workflows. They can either be public or private, meaning that they are either triggered by events (such as a container updating), or they are triggered by a visible button on the UI. Public tends to mean the user can see it, private processes are hooked up to container events and run automatically. (This information is a bit rough but mostly right.)		Phases use Processes, which are a general way of creating logic and actions for Workflows. They can either be public or private, meaning that they are either triggered by events (such as a container updating), or they are triggered by a visible button on the UI. Public tends to mean the user can see it, private processes are hooked up to container events and run automatically. (This information is a bit rough but mostly right.)


	===QESTLab.Repository: Work Template / QESTLab.Workflow: Processes===		===QESTLab.Repository: Work Template / QESTLab.Workflow: Processes===
	~~Create~~ a Work Template for your Workflow:		In the QESTLab.Repository project, create a Work Template for your Workflow:
	* This includes all the Entities you need to create when the user creates a new instance of this Workflow		* This includes all the Entities you need to create when the user creates a new instance of this Workflow
	* Copy existing examples to get the idea. You start with a Work Order and add Entities to it.		* Copy existing examples to get the idea. You start with a Work Order and add Entities to it.
	* In the "Work Templates" folder		* In the "Work Templates" folder

	~~Set~~ up processes to invoke the workflow:		In the QESTLab.Workflow project, set up processes to invoke the workflow:
	* ~~These get turned into~~ buttons ~~in QF~~		* As said elsewhere, processes will be displayed as buttons on the UI to start the Workflow.
			* The files of interest are:
			** "Core/ContainerManager.cs" - Which includes a list of process bundles, and these bundles have a bundle of processes. Each of these will become a button.
			** "/Process Source Bundles/*"
	* You may need to make a new bundle if a relevant one does not exist		* You may need to make a new bundle if a relevant one does not exist
			* Use existing examples to create processes for your Workflow, normally one add and one edit process.
			* Some of the fancier code there will put the edit buttons under the Work Order even if the test normally sits underneath a Sample.


	===QESTLab.Workflow: Container Factories / QESTLab.Models===		===QESTLab.Workflow: Container Factories / QESTLab.Models===

	Models...		Models...

Line 216:		Line 220:

	==QESTField==		==QESTField==

	* Create views		* Create views
	** Views can be tweaked by the styles and tags provided from the container		** Views can be tweaked by the styles and tags provided from the container
	* Update the global.asax file to include the new view folders (if you created new folders)		* Update the global.asax file to include the new view folders (if you created new folders)
	* Update the WorkflowController to route any workspace containers to specific views.		* Update the WorkflowController to route any workspace containers to specific views.

John.meegan at 05:21, 21 October 2015

2015-10-21T05:21:41Z

←Older revision		Revision as of 05:21, 21 October 2015
Line 186:		Line 186:

	Set up Workflow Phases:		Set up Workflow Phases:
	* ... ~~more~~ here		* Phases are used to break Workflows up into multiple pages. There is special coded dedicated to specifying which containers are used on which phases. The same containers can be used, but different sections activated for different steps, e.g. wet and dry weights on 2 separate pages. There is a lot of behaviour here and it can be learnt as required. Any time you want behaviour to change between pages, this is the place to look.
			* The code is normally found at the bottom of the CreateWorkflow() function of the WorkflowFactory.
			* It will look something like "NewProcess.Phase(workflow, "SPD").Targets(siteAndProductContainer)"...

			Phases use Processes, which are a general way of creating logic and actions for Workflows. They can either be public or private, meaning that they are either triggered by events (such as a container updating), or they are triggered by a visible button on the UI. Public tends to mean the user can see it, private processes are hooked up to container events and run automatically. (This information is a bit rough but mostly right.)

	===QESTLab.Repository: Work Template / QESTLab.Workflow: Processes===		===QESTLab.Repository: Work Template / QESTLab.Workflow: Processes===

John.meegan at 04:59, 21 October 2015

2015-10-21T04:59:51Z

@@ Line 173: / Line 173: @@
 Create an Entity Plan:
 * These are used to specify which Entities need to exist on a Work Order for the Workflow to be valid
 * They can optionally load the relations/endpoints on the Entities automatically while doing this test. This means you don't have to do it manually later.
 * Use either a LoadableEntityPlan or EntityPlan for this.
 * See the AsConcreteWorkflowFactory for an example that does not automatically load, which manually loads relations in the CreateWorkflow() function.
 * Note that some relations can't be loaded with a plan, any time the relation is a collection, e.g. specimens. This is because the Workflow will be considered invalid if there are no specimens, and as zero is usually valid, the Workflow will never appear.
@@ Line 183: / Line 184: @@
 * Find the file in the "/Deployment" folder at the top level named QESTField.Enable_Workflows.XXXXX.sql
 * Add a line with the Guid in it here

John.meegan at 04:33, 21 October 2015

2015-10-21T04:33:09Z

@@ Line 119: / Line 119: @@
 * In the "Unit Mappings" folder.
 * By this point you should know if you're going to be saving all values in SI Base, or if it needs to work in QL as well.
-* Under the "Entities" sub-folder, a class needs to be created for each Entity you have with UOM units on it. These provide default configuration for the units. Copy the way others are done. The main thing to remember is for compatibility with QL screens, we provide a set of defaults for the units for each field in the database. For example, traditionally MDD tests have saved masses in grams so we set grams as the default for each of the mass fields. In contrast to this an SI base test would save these values in kilograms. These defaults are set by logic so you can have different defaults for IP units, different QestIDs, etc.
+* Under the "Entities" sub-folder, a class needs to be created for each Entity you have with UOM units on it:
 We hope to automate a lot of this work eventually.
@@ Line 152: / Line 161: @@
 * Namespace the rules appropriately
 * Look at others for examples

John.meegan at 04:10, 21 October 2015

2015-10-21T04:10:34Z

Show changes