Vault-Taylor Print Integration (23YHLR)

# Client-Taylor Print Integration (23YHLR) [https://link.orangelogic.com/Tasks/23YHLR](https://link.orangelogic.com/Tasks/23YHLR) Status: InProgress | When | Who | What | | -------- | -------- | -------- | | 2023-08-24 | Bach Ly | Initial Creation | ## Requirements ### Background Client needs to print custom collateral pieces from the Vault. Currently, they use two printing services - FedEx and an internal ECS Production service. The current FedEx integration is used for the vast majority of orders, and will no longer be supported as of January 31st, 2024. This enhancement is to scope the Taylor option. ### High-level requirements 1. We will deprecate both the existing FedEx API and the ECS Production service 2. The workflow in the Client will be unchanged, except that the user will print to Taylor. - User Inputs when they order a print customization (to be sent to Taylor): - Quantity - Cost Center (Payment method options will be cost center ONLY, credit card payment will NOT be supported) - Shipping information - Other Order Information such as start date, line of business, etc. (captured for record-keeping, not for Taylor) - We got a list of SKUs corresponding to templates in the Vault. We must pass the SKU info through to Taylor when the user places an order so they have the printing specifications. 3) Information that we must receive from Taylor about the user's order, and display in the Vault: - Initial confirmation of receipt by Taylor - Order status when updated (e.g. In Progress, Shipped, Delivered -- Client is fine with whatever statuses Taylor currently offers) - Order ID in Taylor (or whatever unique ID they use) - Shipping tracking information ***Note**: We will need to update the UI of the user's view of their orders to display this information. Right now, info such as FedEx tracking numbers is sent via email to the user, but is not discoverable to the end user in Cortex.* 4) Reports - Client wants reassurance that this change will not negatively impact the WORM report - Custom Collateral Template Usage Report should be updated to show Taylor Printing and still pull in relevant details for orders ## Materials ### Custom collateral Because Client needs to print custom collateral so we need to know which potential flow that they are using. See related documentations: [How to create and submit a customization](https://drive.google.com/file/d/1Qrhf5qT8Zo17EeetXXzKoL-PQShUf_Wj/view). If using Client profile for testing, we need to override some visibility conditions for a simpler procedure. ### Previous Taylor - LMI integration Refer to the [enhancement ticket](https://link.orangelogic.com/Tasks/235ALQ) and [dev note](https://docs.google.com/document/d/1nxAV7BTDluZlQT7clzpmgo2SaTKiZZSiyDGyWO_B9oQ/edit#heading=h.dneote3g3l12). Other helpful pieces of information: - [Old APIs specification](https://apim-service-sharedservices-qa.developer.azure-api.net/api-details#api=boss-api) - [Q&A about APIS](https://link.orangelogic.com/Tasks/237QX4) - The most painful step was [testing phase](https://link.orangelogic.com/Tasks/23LX1O), in which we need back and forth feedbacks. - See the [defect tickets](https://link.orangelogic.com/Tasks/237QWV) to avoid. ### New materials - Taylor has evolved since LMI integration era, see [new APIs (actually document)](https://apim-service-sharedservices-qa.developer.azure-api.net/documentation/api-methods#SncVj) - [Q&A about new APIs](https://link.orangelogic.com/Tasks/4SKC2) ## BOSS API project TaylorCorp ### Client code generation The new api specification is slightly different, so we need to use a new one. Some errors of the specification OpenAPI 3 JSON: - Replace `#/components/schemas/ErrorModel` ---> `#/components/schemas/TaylorCorp.BOS.Api.ApiModels.ErrorModel` - Replace `#/components/schemas/BOSS.Api.Models.InputOutputModels.OrderResponseModel'.` ---> `#/components/schemas/TaylorCorp.BOS.Global.Models.ResponseModels.OrderResponseModel` - Remove the block below. It is under `/customers/{customer_id}/orders/{order_number}` -> patch, which is not used. ``` "requestBody": { "description": "Json Body of order", "content": { "application/json-patch+json; v=1.0": { "schema": { "$ref": "#/components/schemas/Microsoft-AspNetCore-JsonPatch-Operations-Operation-1-TaylorCorp-BOS-Global" } }, "application/json; v=1.0": { "schema": { "$ref": "#/components/schemas/Microsoft-AspNetCore-JsonPatch-Operations-Operation-1-TaylorCorp-BOS-Global" } }, "text/json; v=1.0": { "schema": { "$ref": "#/components/schemas/Microsoft-AspNetCore-JsonPatch-Operations-Operation-1-TaylorCorp-BOS-Global" } }, "application/*+json; v=1.0": { "schema": { "$ref": "#/components/schemas/Microsoft-AspNetCore-JsonPatch-Operations-Operation-1-TaylorCorp-BOS-Global" } } } }, ``` - There is a new endpoint called `/customers/{customer_id}/claims` with an `operationId=get-customers-customer_id-claims` that causes NSwagCSharp to generate 2 Client classes. Meanwhile, we specify the `ClassName=BOSSApiService` => 2 classes with same properties => CompileError. We need to specify an option to handle this issue: ``` <OpenApiReference Include="Specs\boss-api.json" CodeGenerator="NSwagCSharp" Namespace="OrangeLogic.Integration.TaylorCorp.Services" ClassName="BOSSApiService"> <Options>/OperationGenerationMode:SingleClientFromOperationId</Options> </OpenApiReference> ``` ### PostOrder Unchanged ### PostOrderWithConfiguration Implement new interface for stronger API ### GetOrder Update current serviceTo get the order details for "double-check" and update latest info to DB. This should be called inside SyncOrderStatus, when we want to update the order status in our system. ## Cortex-Taylor integration ### GetOrder Call TaylorCorp GetOrder and map response to entity. ### OrderNotification webhook Expose endpoint as a webhook for taylor to send OrderNotification (need a way to config authorization). Receive info, response 200, then call SyncOrderStatus and update latest info to DB. ### PlacePrintingOrder Switch between simple version (old PostOrder) and complex version (PostOrderWithConfiguration), introduce an activation for this. The difference between PostOrder and PostOrderWithConfiguration is `super_model` parameter (**Only use in case the specific SKU has multiple surfaces**): | Field Name | Cortex Mapping | | - | - | | item_parts.id | Get corresponding id from SKU (need user input) | | item_parts.surfaces.id | Auto increment. Most of products have 1 surface only | | item_parts.surfaces.area | We should allow 1 area only | | item_parts.surfaces.areas.id | 1 | | item_parts.surfaces.areas.print_process | configurable on template default: digital | | item_parts.surfaces.areas.print_process_material_id | (optional) relating to color, configurable on template example: "BLK" | | item_parts.surfaces.areas.print_process_material_id_2 | (optional) relating to color, configurable on template example: "106" | | item_parts.surfaces.areas.asset_id | 1 | | assets | same as PostOrder assets | ## FedEx Notifications See param `FedExOfficeOrder_BO.Data.Preferences`, in which email configuration is configured. Notice that email notifications are sent by FedEx, not Cortex. ## FedEx API fields | Field Name | Description | Taylor Equivalence | | - | - | - | | CollateralTemplates.Page-Layout | Print single or double side | See attribute `super_model.surfaces` | | CollateralTemplates.Color-options | Color or black-white | See attribute `print_process_material_id` | | AdHoc MediaCategoryType AdHoc MediaDescriptionType | Product type that FedEx supply | SKU | Other fields are mapped dirrectly from custom fields without further processes. ## Configuration - Activation parameter: UsePostOrderWithConfiguration