Author: Fu Jun Ying

In the last week at Tong Hin, I managed to refactor the cancel ongoing accept stock take command to fit with the refactor background service which uses channel. Afterward, I need to fix the some of the problem for the signalR where the if the process is finished faster than the connection being establish the progress bar will not being updated.

In order to figure on how to fix the existing problem, I needed to mock the signalr service in the background service so the output of the signalr will be display on the unit test instead. The mock is done in order to simulate the client connection which will establish the connection and receive the input from the server.

After some fail attempt in mocking the background service, I move on to doing the code review with Mr. Peter.

As for this week, the problem of the web application factory running the dependency injection during testing was managed to be solve with the help of Mr. Peter. Now the services registered in the dependency injection will no longer be instantiate twice during testing.

Next, after changing the stock take background service to using channel instead of concurrent dictionary. I ran into some problem where the channel is not being dequeue after an item is being queued to the channel. With some help from Mr.Peter, I’m manage to figured the problem was the instantiation of the channel.

The problem was that I instantiate a new channel in the accept command service class hence the item is never dequeue from the channel. Lastly, I refactor the cancel ongoing accept stock take command so that it will work with the current implementation of the background service. Now, I have make so that the channel can take multiple entries and the user will be able to cancel the ongoing accept stock take that they requested.

For this week, I managed to complete the client side of the signalR which will receive the progress of the ongoing accept stock take process. This is done using channel to publish the current accept progress to the client. In order to do this, the server and the client has to be in a group to send and receive the information.

On the server side, the server only has to publish the progress to the proper group. The group name is decided using the guid that is created when the accept command is requested. On the client side, the client on has to join the group using the guid provided to receive the progress.

Lastly, the current problem that I have resolve is to change the background service from using concurrent queue to channel. But when trying to resolve this problem and discussing it with Mr.Peter. I’m require to resolve the problem of the custom web application factory running twice during the testing in order to properly debug the background service.

For this week, I managed to finish up the updating of the progress bar for the UI when they user does the accept command. Furthermore, I also managed to fix the problem of the threading issue when testing the background service. I created another endpoint which will cancel the ongoing accept task if the user wish to cancel it.

The cancel request is POST request which take the guid from the accept command. When the user send the guid, the API will check if the concurrent dictionary with the following guid exist or not. From there, if the dictionary exist, the current accept process will be stopped. Mr. Peter also mentioned to make sure the code doesn’t crash when the cancellation is requested and that the background service will still continue running even an exception is thrown.

Lastly, I need to implement SignalR into the background which would essentially send back the progress of the ongoing accept command instead of having the user request the progress every few seconds. Currently, I still trying to create the client side of the SignalR after creating the server side.

For this week, I’m still focusing on resolving the bug that exist in the UI of the stock take. One of the bug that I managed to resolve is the preview function of the stock take which allow the user to preview the line item without going into the detail page. The main problem of what’s causing is the lack of publisher of the event which resulting in the method that handle loading the data grid with the line item not being called.

Next, I need to create the pagination for the stock take line item which will be in the detail page of the stock take UI. The pagination will be handle in the view model unlike the list page which is handled by the API. Currently, I’m still trying to figure out on how to the pagination for the line item.

Lastly, fixing the background service which created separate during debugging in the testing. After refactoring some of the code, the problem seem to still persist. As of currently, I’m trying to resolve these problem at the moment.

After finishing the design of the UI for the stock take feature, I went and started with the logic of the code which will handle the API calling. The detail page of the stock take will display the stock take together with its line item. This is done by calling the get stock take by id query. In this detail page, the user can create a new stock take and also updating together with deleting existing stock take.

After completing the detail page of the stock take, next is the list of the stock take which will display the list of existing stock takes. In this page, the get stock take list query will be used. Not only that, the user can also the set accept the stock takes through this page. This is done by allowing the user to check on the existing stock takes and clicking on the accept button.

Lastly is the accept part of the stock take. The accept button will use the accept of the stock take API. When the user set accept the stock take, a progress bar will be display to the user. As of currently, the progress bar is not working properly will need to be fixed.

After finishing the accept command of the stock take, The logic of the accept command is then registered as a background service. When the user send an accept command, the API will return a Guid back to the user. The user can then use this Guid to query the status of the ongoing accept command of stock take. The progress of the ongoing accept command is stored in a concurrent dictionary.

From there, the user will use the Guid to query the dictionary and get back the status of the ongoing accept command. After a small discussion with Mr. Peter the query of the status of the accept command should provide more than just the percentage of the ongoing accept command.

Lastly, after finishing the API component of the stock take, I will move on to doing the UI of the stock take using WPF and the MVVM pattern. Firstly, I will create the rough design of the stock take UI and afterward I will implement the logic. Currently I’m doing the design for the details view of the stock take.

As for the final part of the command for stock take is to allow the user to be able to query the status/progress of the ongoing accept command. This is done through the use of concurrent dictionary. The dictionary will hold the value of the progress of the accept command and return it to the user.

Next, I need to create a background service for the concurrent dictionary so that the value can be display to user. To do this, I have to create monitor class to monitor the dictionary and check if the key for the dictionary exist which in this is a Guid. After that, the progress of the accept command can be display to the user. After creating the monitoring class, I have registered it as a singleton in the source code.

Currently I’m still trying to figure out on the logic of the monitor class which will check the dictionary every 5 seconds and report back. I’m also trying to figure out on how to return the value in the dictionary to the monitor class to be presented to the user.

In this week, the final touch up of the accept command for stock take was done. First, the I added a query to get all the stock take that is still pending in accept so the user can easily look up the stock take that they want to accept. Next, A stress test of the accept command logic was done to ensure that the logic is capable to handle large amount of data and do the accept process rather quickly.

The stress test was done with 10000 items, 200 places, 200 places and 300 stock take line items. The entire process of the accept for the large quantity of item took roughly around 5 to 6 seconds. After that, I wrote another unit test which involve the stock take having different items from the existing item list. The test is to ensure the existing item on the following is replaced with the items in the stock take itself.

Lastly, I need to add a query for the accept command in which the user is able to look at the status of the ongoing accept command. Not only that, the user should also be able to cancel the ongoing accept process as well. Once all the touch ups are done, I will move to creating the UI for the stock take feature.

In this week, the accept command of the stock take was further improve on. Firstly, the command will get both the existing item list with the line item for the stock take. From there, the algorithm will compare both the existing item and the new line item. After that, it will update the quantity to the new quantity. The item with zero quantity will automatically be remove from the existing.

Next, I need to rework the function which will update the item list. First, I need to change the parameter that it takes to a list. From there, I need to rework the logic so that I can take the list as the input and update all items at once. Moving on from there, I need to ensure that the update function transaction only run once after being called.

Lastly, I need to change the logic for the updating the existing and matching item so that the last checked date and the last checked by property will match the one in the stock take itself. I then need to do the unit testing to ensure that everything is working fine and as intended. I also completed the testing for most of the logic of the accept command.