Sunday, January 3, 2021

Typical Field Service Platform and Warranty Web Services Implementation with Parts SuppliersTypical Field Service Platform and Warranty Web Services Implementation with Parts Suppliers

If you are a part supplier and you want to be able to sell your parts to the major warranty companies and service providers you will need web services to interface with the major field service platforms. You will need to develop web services to be hosted in your environment and domain based on your selected field service platform’s requirements. Let DRK Resources Tech help you expedite this development process to get you into production within a few months to grow your new revenue stream with the field service platforms and extended warranty providers.

Basic Field Service Platform Web Services :

Part Search – Search for a part by manufacturer and part number. Returns price and availability sorted by the best geo ship location where the parts are needed.

Order Part – Allows the field service platform to place orders for parts. Returns part supplier’s order number, claim/dispatch number, line items, and cost as the order conformation.

Order Status – Enter order number, or claim/dispatch number. Returns current part order status for each line item and includes shipping tracking numbers.

Return Material Authorization (RMA) – Enter order number or claim/dispatch number and part numbers being returned. Returns a RMA number and shipping label with a RMA bar code number to be placed on the shipping box for the part return.

Cancel – Enter order number or claims/dispatch number and part numbers for the parts to be canceled before they were picked, packed, and shipped. Returns a cancel conformation number, order number, claim/dispatch number, and canceled part numbers.

Invoice Inquiry – Enter order number or claims/dispatch number. Returns the invoices.

Model and Parts Search (optional) – Enter a model number. Returns part diagrams and list of part numbers for that model (bill of materials).

Project Assumptions :

A Cost Benefit Analysis (CBA) was done to make sure this field service platformimplementation will have a positive return on investment for the development cost within 6months to a year after the field service platform web services are put into production and generating new revenue.

Your companies management team or IT governance committee approved the project budget, priority, and gave you a project start date and desired production date.

You understand the field service platform’s cost structure to sell parts on their field service platform.

You have a legal review and sign off on the service agreement and make sure to pay attention and understand the details of any service level agreements (SLA’s) and potential liability or payments for downtime.

You have a internet and data security review and sign off on the service agreement’s technical details and requirements of the platform for security risks and potential liability.

Have a field service platform technical details and requirements review and sign off from your development manager.

You have a signed service agreement with the field service platform company that you selected.

We assume that you have existing application programs in your environment that have the same business functions as the field service platform’s web services you are going to develop. For instance you, should already have the following programs Parts Search, Order Part, Order Status, Cancel, and RMA. We assume that these programs can be called from within your newly developed web services by means of a remote procedure call, stored procedure, existingweb service, or called from a DB driver like JDBC or ODBC. If you don’t have existing programs that can be wrapped to make these new field service platform web services this can double the implementation time to develop these business functions within new programs.

You have selected the proper resources for the web services development from start to finish. These resources can be internal employees, external consultants , remote, or on-site.

Highly recommend the use of the Agile development framework and have 2 week development sprints.

Your company has a project management framework and a project manager assigned to this project.

You have a development tracking tool like Jira for tracking requirements, development, issues, and bugs.

Your company has programming development standards along with approved programming languages, and web services frameworks.

Your company has a change management process that includes function testing, integrationtesting, user acceptance testing, test plans (that includes test data and desired results), vulnerability scans, and includes a approval process to get from development to production.

Your development team has expertise in web services, api gateway, https, restful, soap, user authentication, xml, and json. Some of the older field service platforms may require soap and xml instead of rest and json. Json and xml can be used interchangeable in this document depending which data format you will use for this development.

You have a development and user acceptance testing environments on premise or in a cloud hosting environment.

You have a production hosting environment on premise or in a cloud hosting environment.

You have a existing internet domain name to host the web services on the internet.

You have or plan to use a api gateway to call the web services, secure users authentication, load balancing, throttling, and user logging.

You have a new or existing domain SSL/TLS cert for data encryption in flight over the public internet.

You have a existing internet vulnerability solution to scan your web services for web application vulnerabilities.

You have 24 hours a day by 365 day production support.

You have a monitoring solution that can notify your support team before you get called from your selected field service platform that your web services are down or not functioning properly.

You have your daily development code backed up to a private software repository branch for development along with a uat and production code master branch. This could be Git, GitHub, BitBucket, etc. These repositories need to be locked down and grant users the proper access to secure this source code for their IT role.

Development :

Have a list of all your identified existing programs that will be used within the new field service platform web services.

You have identified the protocol and the methods to call these existing programs from within the new developed field service platform web services.

You have identified all the input data (request), data validations, and output (response) parameters for your existing programs.

List the URL’s for the new web services. These named resources will have to match therequirements from the field service platform for both production and uat. It is usually https://yourdomain/businessfunction for production and https://test.yourdomain/businessfunction for uat. Data should be passed to the web services secured in the HTTP headers and use standard http methods post, get, put, patch, and delete.

Examples :
https://yourdomain/PartSearch
https://yourdomain/OrderParts
https://yourdomain/OrderStatus
https://yourdomain/RMA
https://yourdomain/Cancel
https://yourdomain/InvoiceInquiry
https://yourdomain/ModelPart

Map the request data from the field service platform's requirements for all the web services to your existing programs that will process that web service request and return the proper json response. Make sure that data attributes between the field service platform’s requirements and your existing programs match.

Map the response data from the field service platform’s requirements for all the web services to your existing programs that will process that web service request and return the proper json response. Make sure that data attributes between the field service platform’s requirements and your existing programs match.

Start the development of the web services with your selected development team, web services frameworks, and agile software development process. This new development will be done in your development environment.

Developers to do functional testing based on a written test plan with a manual or software testing tool. Make sure all test results get recorded as proof they were tested. Developer to refactor for errors until they get the proper test results.

When all testing passes the test use cases, the developer can then move the functioning web services into the uat environment on the internet with your exiting uat change control process.

Configure the uat web services with the api gateway along with creating user profiles and security roles. You need to make sure these web services are secured and does user logging.

Work with your field service platform’s team to have them start their user acceptance testing. All issues and bugs get documented in the development tracking tool and sent to the developer to resolve and get tested again until resolved.

Once all the issues and bugs have been resolved, start your change control process to get sign off along with a date and time for production go live. Make sure your web services were scanned by your internet vulnerability solution and no major vulnerabilities were found. All vulnerabilities go back to the developer to resolve until they get a clean scan.

On the go live date and time, follow your change management process then move the web services into production (a manual move or an automated software tool). Next setup user profiles on production api gateway. You should also have a go live checklist and a move to production test plan with your selected field service platform.

Now that the web services are in production, address all issues immediately by documenting them in your development tracking tool and send to the developer to resolve. Keep a good watch over the web services for a few weeks. Make sure all issues get resolved in a timely manner.

After a few weeks in production, follow your companies documented normal support plan and escalation process.

Continue reading all articles >>