Category: Experiential

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.

Begun development on the new features including the barcode, ids, remark, and name fields. Upgraded the test cases to ensure that these fields are valid. Moreover, I began work on a new feature, which will include the addition of a selling price, discount, and with tax computation and test cases. introduced logic for calculating the subtotal amount after taxes, then moved on to creating the test case. Encountered a difficulty with relation due to the fact that one tax can have numerous line items.

Next. I fixed The issue in the relationship which was that the code misinterpreted it as a one to one relation. Once fixed, I tested out Create Command (since now, when a Order is created, the total amount is computed. Similarly, calculating logic was added to the Update Command and tested.

Lastly, built Status entity which has a one to many relation with Order and provided relevant fields. The aim of status is to inform the cashier about the progress of the order. Started considering the structure of Payment.

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.

Following last week, I continue the implementation of the stock take. This week, I implemented functions, struggled with some logic, and modified the list component, among other things.

First, after successfully retrieving the data of the item list in the detail view, various tasks remained. Such as the search and pagination functions in both views. I added pagination and the possibility to search by barcode or item name to the list view. The data size was restricted by the API call, thus this was a fairly straightforward process.

Next, I was tasked with developing a specific search feature for the detail view. This search is not intended to filter the data, but rather to navigate to the page containing the item. This is where I ran into trouble creating the pagination this time because the Flatlist component did not make it easy. Mr. Peter then suggested I replace the Flatlist component used for the data table with the DataTable component.

Last, after implementing the Datatable component, I was finally able to view the data. I encountered one obstacle, which is pagination, but I was able to overcome it by separating the data into chunks and mapping the values between the first and last index in each chunk to the list. In the coming week, I must complete the search feature and carry on to next tasks.

I started off the week by adding more test cases for the Update command, observing the update logic in different scenarios. Found out there was a bug in the Update logic which was allowing the code to update the line items with Ids that were already taken before and also which did not yet exist. 

After some brainstorming I was finally able to fix the bug. I added a piece of code which acted as validation for Ids. It would throw an error if the LineItem Id that was provided was not present in that retail order.

Next, I got a new task to add a new field of Order No which was to be generated by a sequence generator. Purpose of adding this field was to give each order a distinguished identity, as we won’t be using their Ids as identification in actual business. Following this change I made changes to my Create command Handler so that now it creates a new sequence whenever an Order was created.

Now it was time to test my Create command which was modified with a new feature. I was able to successfully run 3 test cases, for the test cases I had to create a new Sequence Generator Id then pass it into the Create function which was then handled, by Create logic handler, and a OrderNo would be created. To test if my transaction which I added last week, I created a test case that would fail and observed if the transaction rolled back to the last savepoint.

Had a problem with validating the Sequence Generator Id as it was optional to input when there is no Id created, after discussing with my supervisor we came to the conclusion to not include a validation for the Sequence Generator.

Furthermore, I wrote test cases for Update command testing the Order No update and altered the DTO of Get query to output the Order No to the user.

Since a basic model of API was done, I was introduced to new tasks and features to make the API more robust.

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.

This week I had only one major objective, which was to complete the new Stock Take module.

After constructing the detail view layout last week, I began this week by creating the layout for the Stock Take list view. The List view will display all of the created stock takes. However, as no data had yet been received from the API, I had to continue developing the detail view.

Furthermore, I needed to retrieve data from the API in the detail view.
It took me quite a while time to input the data and review the list of stock takes. One major issue I had was that I couldn’t make a successful Post request to create the stock stake and kept failing at it. One of the reasons was that I had no validations for the barcode and other data.

I was able to create the validators. By doing so, as well as accessing the API to retrieve item data, I was able to debug the problem more easily than previously. Furthermore, it took some time for me to create the POST request and ensure that the data was correctly sent to the database.

Continue back to the list page, where I was able to access the list of created Stock takes after successfully retrieving the data. In addition, I wanted to utilise the getStockTakeById request to view or modify a particular stock take. And after some effort with the code, I was able to successfully get it to function, allowing me to access the stock take and make any changes.

By the end of the week, I believed I was nearly finished since it appeared functional to me. However, because of a conflict with the API, I was required to map the data manually from one type to another. This was totally new to me since I had very blurry vision on it, studying that and implement it correctly is the next thing to do.

I spend my third week mostly working on a complex command Update and fixing bugs in my code.

I started off the week by adding more test cases in the Repository test file, the purpose behind this was to test if my repository is correctly performing the CRUD operations. After this, I realized that I’m yet to write test cases for data which should have been done once the entities were created as these test cases help ensure the data type of each field is consistent.

Next, I shifted my focus to correctly format my API test cases, of Create and Delete, according to the norms of 3 A’s which are Arrange, Act and Assert. Moreover, I improved my test cases by adding more assertions. 

Finally, I started on coding the logic of the Update command which was challenging because Updating every field can have multiple possibilities.

After coding the logic I realized there was a bug which was occurring when an existing line item was removed and a completely new one was added. Once the bug in the UpdateHandler was fixed, I added the controller which handles the whole PUT request.

Lastly, I moved my focus on testing the Update Command. On running the test case gave me an error report ‘database operation expected to affect 1 row(s) but actually affected 0 row(s)’ error. After a lot of unsuccessful debugging I finally sought help from my supervisor who helped me find the bug and explain to me the root cause of it. This error was due to the primary key which I was hardcoding inside my update logic. We are not supposed to set the primary key as the database does it for us automatically.

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.