FS 292887 ePOD Exception Handling - Revision history

Anw: v1.0 - Issued after final updates

2011-10-17T09:19:05Z

v1.0 - Issued after final updates

← Older revision		Revision as of 11:19, 17 October 2011
Line 158:		Line 158:

	==== Job Lock Response ====		==== Job Lock Response ====

	~~{{comment\|text=All child elements from EPOD_JOB are not required\|sign=[[User:Milesl]]\|date=5/9/2011 17:4:44}}~~

	<JOB_LOCK_REQUEST ID="X">		<JOB_LOCK_REQUEST ID="X">

Anw: v1.0 - Issued after final updates

2011-10-17T09:16:21Z

v1.0 - Issued after final updates

← Older revision		Revision as of 11:16, 17 October 2011
Line 4:		Line 4:
	{{#vardefine:System\|''CALIDUS'' ePOD}}		{{#vardefine:System\|''CALIDUS'' ePOD}}
	{{#vardefine:Doc_Title\|ePOD Exception Handling}}		{{#vardefine:Doc_Title\|ePOD Exception Handling}}
	{{#vardefine:Version\|0.1}}		{{#vardefine:Version\|1.0}}
	{{#vardefine:Date\|~~14th~~ October 2011}}		{{#vardefine:Date\|17th October 2011}}
	{{#vardefine:Reference\|292887}}		{{#vardefine:Reference\|292887}}
	</div>		</div>

Anw at 09:13, 17 October 2011

2011-10-17T09:13:21Z

← Older revision		Revision as of 11:13, 17 October 2011
Line 45:		Line 45:
	== Pre-requisites ==		== Pre-requisites ==

	There are no additional ~~pre-requistites~~ for this new functionality other than those of the ~~intial~~ system.		There are no additional prerequisites for this new functionality other than those of the initial system.

	== Menu Structure ==		== Menu Structure ==
Line 80:		Line 80:
	=== Admin Process ===		=== Admin Process ===
	The admin interface will need to be altered to allow for handling for exceptions for jobs in two ways:		The admin interface will need to be altered to allow for handling for exceptions for jobs in two ways:
	*It will require in any menus that allow users to edit or delete load, jobs, services, container and products, to have a mechanism that will start a transaction on the record, and then check the status on the Job, if at status I this must be ~~canceled~~ and the transaction rolled back.		*It will require in any menus that allow users to edit or delete load, jobs, services, container and products, to have a mechanism that will start a transaction on the record, and then check the status on the Job, if at status I this must be cancelled and the transaction rolled back.
	*The Service and Job screens will be modified to allow for admin users to change the status of loads and jobs at the status of In Progress, as well as allow for a user to deallocate a PDA user from a Job or Load. This will be to prevent Jobs being locked in the system.		*The Service and Job screens will be modified to allow for admin users to change the status of loads and jobs at the status of In Progress, as well as allow for a user to deallocate a PDA user from a Job or Load. This will be to prevent Jobs being locked in the system.

Line 217:		Line 217:
	</EPOD_LOAD>		</EPOD_LOAD>
	</LOAD_UPDATE_RESPONSE>		</LOAD_UPDATE_RESPONSE>


	<!-- NEW PAGE -->		<!-- NEW PAGE -->
Line 229:		Line 228:
	\|REQ=0		\|REQ=0
	\|EST=0		\|EST=0
	\|FS=0		\|FS=2.0
	\|TS=0		\|TS=0
	\|DEV=0		\|DEV=14.0
	\|ST=0		\|ST=2.0
	\|IMP=0		\|IMP=0
	\|Client={{#var:Client}}		\|Client={{#var:Client}}

Anw: /* Process 2: Load Update */

2011-10-17T09:11:14Z

Process 2: Load Update

← Older revision		Revision as of 11:11, 17 October 2011
Line 86:		Line 86:

	This mechanism will perform the second process to handle exceptions.		This mechanism will perform the second process to handle exceptions.

			=== Database ===
			The Load, Job, Service, Product and Container records will be modified to include Last Changed Date/Time fields.
			These will be identical in design and naming convention to the records added to the Site table.

	=== PDA Process ===		=== PDA Process ===

Anw: /* Set-up */

2011-10-17T09:09:32Z

Set-up

← Older revision		Revision as of 11:09, 17 October 2011
Line 54:		Line 54:

	== Data ==		== Data ==
	~~No database changes will be required.~~		None

	<!-- NEW PAGE -->		<!-- NEW PAGE -->

	= Functional Description =		= Functional Description =

Anw: /* Menu Structure */

2011-10-17T09:08:56Z

Menu Structure

← Older revision		Revision as of 11:08, 17 October 2011
Line 48:		Line 48:

	== Menu Structure ==		== Menu Structure ==
			No menu structure changes will be made to the PDA or Admin systems.
	~~=== PDA ===~~
	No menu structure changes will be made.

	~~=== ADMIN ===~~

	== Server ==		== Server ==

Anw: /* ADMIN */

2011-10-17T09:08:17Z

ADMIN

← Older revision		Revision as of 11:08, 17 October 2011
Line 53:		Line 53:

	=== ADMIN ===		=== ADMIN ===
	~~The additon of a Process Lock Management screen/s will be added to the Admin tab in the menu.~~

	== Server ==		== Server ==

Anw: /* Admin Process */

2011-10-17T09:07:53Z

Admin Process

← Older revision		Revision as of 11:07, 17 October 2011
Line 86:		Line 86:
	The admin interface will need to be altered to allow for handling for exceptions for jobs in two ways:		The admin interface will need to be altered to allow for handling for exceptions for jobs in two ways:
	*It will require in any menus that allow users to edit or delete load, jobs, services, container and products, to have a mechanism that will start a transaction on the record, and then check the status on the Job, if at status I this must be canceled and the transaction rolled back.		*It will require in any menus that allow users to edit or delete load, jobs, services, container and products, to have a mechanism that will start a transaction on the record, and then check the status on the Job, if at status I this must be canceled and the transaction rolled back.
	*~~Two new~~ screens will ~~need to~~ be ~~added~~ to allow for admin users to change the status of loads and jobs at the status of In Progress, as well as allow for a user to deallocate a PDA user from a Job or Load. This will be to prevent Jobs being locked in the system.		*The Service and Job screens will be modified to allow for admin users to change the status of loads and jobs at the status of In Progress, as well as allow for a user to deallocate a PDA user from a Job or Load. This will be to prevent Jobs being locked in the system.

	~~{{comment\|text=Why not allow the admin user to do this straight from the Jobs and Services screens that already exist?~~
	~~\|sign=[[User:Anw]]\|date=17/10/2011 9:37:5}}~~

	== Process 2: Load Update ==		== Process 2: Load Update ==

Anw: /* Load Update Request */

2011-10-17T09:05:32Z

Load Update Request

← Older revision		Revision as of 11:05, 17 October 2011
Line 188:		Line 188:

	==== Load Update Request ====		==== Load Update Request ====

	~~{{comment\|text=This will not work unless the server cascades last changed dates through all parent records or at least the load\|sign=[[User:Milesl]]\|date=5/9/2011 17:4:44}}~~

	<LOAD_UPDATE_REQUEST ID="X" SITE="XXX" USER="XXX" PASSWORD="XXX">		<LOAD_UPDATE_REQUEST ID="X" SITE="XXX" USER="XXX" PASSWORD="XXX">

Anw: /* Process 2: Load Update */

2011-10-17T09:04:39Z

Process 2: Load Update

@@ Line 96: / Line 96: @@
 === PDA Process ===
-This process will run in a threaded process similar to the pending data process. As with the pending data process a parameter will need to be set to control the occurence of the Load Update Process. Once every X seconds, if the network is available the PDA client will send a Load Update message, and wait for a response.
+This process will run in a threaded process similar to the pending data process. As with the pending data process a parameter will need to be set to control the occurrence of the Load Update Process. Once every X seconds, if the network is available the PDA client will send a Load Update message, and wait for a response.
 From which the following scenarios can occur:
-*The PDA recieves a message advising that there are no updates, in which case there is no processing to be done and the process ends.
+*The PDA receives a message advising that there are no updates, in which case there is no processing to be done and the process ends.
-*The PDA recieves a message advising that there are updates. At this point the PDA would need to create the Load object and decode and apply the changes. If the user is in the Job  List, this list can simply be refreshed to reflect the changes.
+*The PDA receives a message advising that there are updates. At this point the PDA would need to create the Load object and decode and apply the changes. If the user is in the Job  List, this list can simply be refreshed to reflect the changes.
 :If the user is processing a Job, the process must do one of two things:
-:*In the case where the job has been deleted the user must imeditatley be prompted. At this point the job will be deleted from the device and the user will be returned to the Job List.
+:*In the case where the job has been deleted the user must immediately be prompted. At this point the job will be deleted from the device and the user will be returned to the Job List.
-:*In the case where the job, this will include any containers, products or service records, the user will be promted that there has been a update and will be returned to the first tab of the menu they are using.
+:*In the case where the job, this will include any containers, products or service records, the user will be prompted that there has been a update and will be returned to the first tab of the menu they are using.
-*The PDA recieves a NAK due to a error. At this point the application should ignore the update and end the process.
+*The PDA receives a NAK due to a error. At this point the application should ignore the update and end the process.
-*The PDA recieves no response. At this point the applcation should ignore the update request and end the process.
+*The PDA receives no response. At this point the application should ignore the update request and end the process.
 === Server Process ===
 When the server receives a Load Update message, it will initial create the Load Object. Then the system will use the Load object to check for updates recursively against the job, service, containers, and products. Any elements that have been updated will be added to the response message. Any elements that haven’t been changed will be added as a single record, allowing the PDA to identify deleted records, as they will not be present. It will then respond with this message.
 == XML Schema ==

← Older revision		Revision as of 11:16, 17 October 2011
Line 4:		Line 4:
	{{#vardefine:System\|''CALIDUS'' ePOD}}		{{#vardefine:System\|''CALIDUS'' ePOD}}
	{{#vardefine:Doc_Title\|ePOD Exception Handling}}		{{#vardefine:Doc_Title\|ePOD Exception Handling}}
	{{#vardefine:Version\|0.1}}		{{#vardefine:Version\|1.0}}
	{{#vardefine:Date\|~~14th~~ October 2011}}		{{#vardefine:Date\|17th October 2011}}
	{{#vardefine:Reference\|292887}}		{{#vardefine:Reference\|292887}}
	</div>		</div>