Level of Assurance - RDIMS 19532524
Statement of Sensitivity - RDIMS 19532575
This guide will help your team integrate Cost Recovery Service Management (CRSM) requirements into your Workload Management (WLM) platform. There are checklists to make sure required data points are captured, as well as descriptions of the various features and UI components that are available for you to use.
Prerequisite: - Following information needs to be obtained through MTOA and CRSM before onboarding CRSM through WLM. For more information, refer to the CRSM Onboarding Guide.
(1) Service Id | Service ID created by MTOA for LoB |
(2) Attribute Id | Attributed Id created by MTOA for LoB service. Please note AttributeId is NOT the same as service attributesID. |
(3) API Key and JWT token to access MTAPI | API Key and JWT token created by MTOA for LoB |
(4) Service Standard | Service Standard created by CRSM for LoB |
(5) Service Attributes | Service Attributes created by CRSM for LoB |
How to verify the above information:
On CRSM Service Inventory Service, it contains all the information regarding those attributes.
https://wwwappstestext.tc.gc.ca/Corp-Serv-Gen/5/siapi-isapi-dev/swagger/
(1) To check CRSM Service Id, Attributes, and LOB Request Type relationship, we can use following endpoint of SIAPI: api/v2/attributes/byservice/{serviceId}
(2) To Check CRSm Service Id, AttributesId, and ServiceAttributesId relationship, we can use following endpoint of SIAPI: pi/v2/serviceattribute/serviceId
={serviceId}
Step 1:
After verifying the information above, LOB can further plug those information into LOV for LO, please note, How to plug those information into LoV or whether LOB needs to plug those information into LOB is pure LOB design decision. We here is just providing the recommendation here.
[ { "id": "022", <--- This should be RequestTypeId mapping to VR request Type "listOfValueType": "VesselRegistryReqeustCRSMServiceMapping", "valueTextEnglish": "First Registry", <--- This can be copied from Service Inventory under Service Attributes "valueTextFrench": "First Registry", "order": 1, "customValue1": "", "customValue2": null, "parentList": null, "isTypeActive": true, "isValueActive": true, "searchCriteria": null, "ownerShips": [ { "businessName": null, "businessOwner": null, "businessContactEmail": null, "businessContactPhone": null } ], "customProperties": [ { "ServiceId": "9999", "AttributeId": "-1", "ServiceAttributeId": "3596" } ] }, { "id": "044", "listOfValueType": "VesselRegistryReqeustCRSMServiceMapping", "valueTextEnglish": "Renewal", "valueTextFrench": "Renewal", "order": 2, "customValue1": "", "customValue2": null, "parentList": null, "isTypeActive": true, "isValueActive": true, "searchCriteria": null, "ownerShips": [ { "businessName": null, "businessOwner": null, "businessContactEmail": null, "businessContactPhone": null } ], "customProperties": [ { "ServiceId": "9999", "AttributeId": "-1", "ServiceAttributeId": "3598" } ] } ]
After storing those information above, LoB can use the following sample demo portal project to start the development to onboard with WLM and integrate with CRSM: WLM Demo Portal Repos
Step 2:
LoB just needs to send following piece of information in topper level of details of Work Item when creating WorkItem, and remaining communication between CRSM will be auto handled by WLM.RequestTypeId, ServiceId, AttributeId
For Example: {"RequestTypeId":"022","ServiceId":"9999","AttributeId":-1}
The following diagram illustrates how those independent systems work together internally.
Existing Reference Architecture
Please see attachedCRSM Integration Docfor details. As always, please feel free to contact with MOLE team for further help needed.
You are Done!
Enhancements/Updates: During the CRSM integration with Vessel Registry(LOB 001). We found some interesting stuff that would be helpful and avoid the hiccups for other lines of business to consider or implement. The following are the important to consider:
Payment event and expected values from LOB:
When you update or save payment details from your application before or after a service request is completed to generate remissions or invoicing on the CRSM side, WLM expects the following values to be provided to update the payment table in WLM. Once we receive the payment details, then the WLM forward the same to the CRSM side via service bus to generate invoicing.
The details are: Work Item ID, Payment Receipt Number, and Payment Amount
If you are using WLM v2 endpoints, you might need to pass additional information like invoice number and transaction ID
How to add or edit new statuses:
First, find out the list of value types available in LOV by calling the endpoint:
https://ncdlistofvalueapp01.azurewebsites.net/api/v2/ListOfValueTypes?showOnlyActivated=false
Once you identify the corresponding status has been available in the list and is active, then get the list of values for the value type,
For example: A list of value types for “VesselREgistryRequestStatus” is enabled.
You can now get the actual list of values for “VesselRegistryRequestStatus” using the below endpoint:
https://ncdlistofvalueapp01.azurewebsites.net/api/v2/ListOfValues?ListOfValueType=VesselRegistryRequestStatus
If you would like to add the new status to an existing one, you need to call the PUT endpoint.
You need to add the LOB status in “MTOAStatus” by querying it first as like below, once you get the list, you need to add custom properties as highlighted in RED below:
You need to pass the LineOfBusinessId, ListOfValueType, LOBStatusId and ServiceId:
https://ncdlistofvalueapp01.azurewebsites.net/api/v2/ListOfValues?ListOfValueType=MTOAStatus
A common list of statuses that MTAPI maintains for MTOAStatus are listed in this excel sheet attached here:
How to evaluate service performance:
How to evaluate remissions:
How to evaluate invoicing:
Introduction of MTOAStatus mapping:
Implementation of using generic system id:
How to reach MTAPI platform in case of any issues/failures:
Need to update LOV values in ListOfValueService.