Anw: v0.4 - Changes after review, additional scope and corrections to trigger naming.

2020-05-19T15:06:39Z

v0.4 - Changes after review, additional scope and corrections to trigger naming.

← Older revision		Revision as of 17:06, 19 May 2020
Line 5:		Line 5:
	{{#vardefine:SystemCode\|CTMS}}		{{#vardefine:SystemCode\|CTMS}}
	{{#vardefine:Doc_Title\|FleetCheck Interface}}		{{#vardefine:Doc_Title\|FleetCheck Interface}}
	{{#vardefine:Version\|0.3}}		{{#vardefine:Version\|0.4}}
	{{#vardefine:Date\|19th May 2020}}		{{#vardefine:Date\|19th May 2020}}
	{{#vardefine:Reference\|370536}}		{{#vardefine:Reference\|370536}}
Line 88:		Line 88:
	* Carriers and Category may be maintained separately without an interface, but this may result in messages failing to be processed.		* Carriers and Category may be maintained separately without an interface, but this may result in messages failing to be processed.
	* Vehicle and trailer types should be created and maintained within CTMS. As this is a CTMS convention rather than a FleetCheck one, this should be the responsibility of CTMS.		* Vehicle and trailer types should be created and maintained within CTMS. As this is a CTMS convention rather than a FleetCheck one, this should be the responsibility of CTMS.


			{{Note}} This interface is at system level, and therefore any carriers with named resources will be managed through FleetCheck, when this system is enabled. In the future, the system may be modified to enable/disable the interface on a per-carrier basis.

			{{Note}} It may be that, when adding a record into CTMS and therefore triggering the add of the record in FleetCheck, that this may already exist. In this case, the process will log the failure, if a failure code is returned - it will not then attempt to call the web service method again to update the existing record. It is expected that, if this were required, then the FleetCheck web services should support that automatically, as the CALIDUS web services will.


Line 514:		Line 519:

	The .NET code written should be separated into DAL and BAL objects. BAL objects should define the actions being taken for each web service method, for example AddDriver, UpdateDriver or AddUpdateDriver. These will call define DAL object methods. DAL objects should contain the call the the CTMS Oracle package code - Oracle should not be referenced in any other places in the code, as this web services project may be converted to work with SQL Server for CTL TMS or for C-ePOD.		The .NET code written should be separated into DAL and BAL objects. BAL objects should define the actions being taken for each web service method, for example AddDriver, UpdateDriver or AddUpdateDriver. These will call define DAL object methods. DAL objects should contain the call the the CTMS Oracle package code - Oracle should not be referenced in any other places in the code, as this web services project may be converted to work with SQL Server for CTL TMS or for C-ePOD.

			If adding a record that already exists, the process should look to update it. If updating a record that doesn't already exist, if the process has enough key information to create the user, then the process should create it instead.


Line 907:		Line 914:
	Any triggers that must update FleetCheck should call the appropriate procedure within DP_FLEETCHECK.		Any triggers that must update FleetCheck should call the appropriate procedure within DP_FLEETCHECK.

	All triggers should be named appropriately to the table following system conventions~~, and suffixed with "_FLEETCHECK"~~.		All triggers should be named appropriately to the table following system conventions.

	For example:		For example:

	~~TRG_RES_TRAILER_TYPE_FLEETCHECK~~		TRG_RES_TRAILER_TYPE_BUI

			All FleetCheck code should be clearly marked in these triggers (as they may already exist and the code will be added to them).


Line 946:		Line 955:

	If this is in the error range (400), this should be audited so that it is visible in the existing EDI Log screen as an error. Any data included in the error returned should be kept as part of the audit.		If this is in the error range (400), this should be audited so that it is visible in the existing EDI Log screen as an error. Any data included in the error returned should be kept as part of the audit.


			{{Note}} It may be that, when adding a record into CTMS and therefore triggering the add of the record in FleetCheck, that this may already exist. In this case, the process will log the failure, if a failure code is returned - it will not then attempt to call the web service method again to update the existing record. It is expected that, if this were required, then the FleetCheck web services should support that automatically, as the CALIDUS web services will.


Line 1,041:		Line 1,053:
	* ''CategoryName'' - the retrieved carrier name from RES_CARRIER.CARRIER_NAME.		* ''CategoryName'' - the retrieved carrier name from RES_CARRIER.CARRIER_NAME.

	Furthermore, all other entries for that driver against other carriers will be set to ~~INACIVE~~ = "Y". The process will update all of these records at the end of the process.		Furthermore, all other entries for that driver against other carriers will be set to INACTIVE = "Y". The process will update all of these records at the end of the process.


Line 1,069:		Line 1,081:
	* ''CategoryName'' - the retrieved carrier name from RES_CARRIER.CARRIER_NAME.		* ''CategoryName'' - the retrieved carrier name from RES_CARRIER.CARRIER_NAME.

	Furthermore, all other entries for that tractor against other carriers will be set to ~~INACIVE~~ = "Y". The process will update all of these records at the end of the process.		Furthermore, all other entries for that tractor against other carriers will be set to INACTIVE = "Y". The process will update all of these records at the end of the process.


Line 1,098:		Line 1,110:
	* ''CategoryName'' - the retrieved carrier name from RES_CARRIER.CARRIER_NAME.		* ''CategoryName'' - the retrieved carrier name from RES_CARRIER.CARRIER_NAME.

	Furthermore, all other entries for that trailer against other carrier groups will be set to ~~INACIVE~~ = "Y". The process will update all of these records at the end of the process.		Furthermore, all other entries for that trailer against other carrier groups will be set to INACTIVE = "Y". The process will update all of these records at the end of the process.
	<!-- INTERNAL COSTS		<!-- INTERNAL COSTS

Anw: v0.3 - Updated technical details after review. Added estimate.

2020-05-19T11:43:58Z

v0.3 - Updated technical details after review. Added estimate.

Show changes

Anw: v0.2 - Added technical details.

2020-05-14T13:13:20Z

v0.2 - Added technical details.

Show changes

Anw: v0.1 - Initial draft version - incomplete

2020-05-06T15:17:11Z

v0.1 - Initial draft version - incomplete

Show changes

FS 370536 FleetCheck Interface - Revision history

Anw: v0.4 - Changes after review, additional scope and corrections to trigger naming.

Anw: v0.3 - Updated technical details after review. Added estimate.

Anw: v0.2 - Added technical details.

Anw: v0.1 - Initial draft version - incomplete