Development Steps and Estimated Timelines

This section will cover some high level planning steps, questions and estimates to give the reader an idea of the process to develop new web services.

There are several high level steps that generally occur to create new web services.

• Planning
• Design
• Development
• Deployment

We will break those out and a few more in the section below.

Planning

For the early planning phase, there are some decisions and questions to asks.

• Deciding on the high-level goals of the integration
• Determining the appropriate team members
• Gaining consensus
• Establishing a budget and dedicating resources.
• Brainstorming possible approaches
• Researching and prototyping alternative solutions and tools.

Design

For greenfield web services, the design is often an iterative process between the team developing the web service and the team consuming the web service. That is assuming the server team is developing web services for some specific use case and the client is already known. There are other cases where you may be developing services that are going to be used by some future unknown client(s) and you have to answer these with your own judgement.

Here are some high-level questions.

• What information will be exchanged?
• How many web services are needed to accomplish task?
• Who drives the data mapping?
  • Will the client send in data objects based on what the server wants?
    • Will the server decode the client data objects and map them to the server required format?
    • Generally, the client has to conform to the server’s data model. This can present issues if the client does not have all the programmatic codes used to update the server data.
    • Does the client know about the server codes, lookup values, etc?
• How are errors returned and encoded?
  • Can you recover or replay errors?
    • Depending on the integration, the sending system may not be able to replay the event if an error occurred.
• What data encoding is supported? XML, JSON, CSV, Binary, etc
• How is data security handled if needed?
  • Should the client only see a subset of the data on the server?
• How is logging handled?
  • How are errors logged and responded to?
• What is the volume of the web service and will it cause performance bottlenecks?
• For update web services, can you rollback if there are errors?
  • How are database commits handled? There are cases where the client may be sending data that needs to update several components. That maps to different database commits.
• Is it important that services process in a special order in the queue or can they process out of order?
• Is the client coming from a trusted server “inside” the firewall or over the internet?
• Is the service intended to be called by end user’s in their browser or by some trusted server acting as a super-user?
• How is authentication going to be handled?

It is very important that you document these decisions in a design document to guide the development team on the vision and purpose of the web services. What is developed might be based on certain constraints that were in place. Future team members may not be aware of those constraints.

Development & Unit Testing

The development is where all the work happens. There are several hurdles that you have to overcome:

• For someone new to web services, you will struggle on many fronts include unit test tools, debugging, and logging.
• You need to gain expertise on the business process you are integrating.
• If you were not involved in the planning and design phases, then you will need to spend some time getting up to speed on previous decisions.
• For complex business process you will struggle to find test cases to unit test with.
• Then you need to write the actual code.

Security

We touched on a few different security points in the design section. Security is very important in any application. PeopleSoft carries sensitive information. The code must be “secure”.

• What is the authentication mechanism?
  • In PeopleSoft you are pretty much stuck with something like basic authentication.
  • If you have some sort of API Gateway in front of the integration broker, you have many more options like oAuth.
• If you are providing a web service to a client, how do you ensure that they can only see and update data that they are authorized to see?

Testing

The testing phase can be complex depending on who and what you are integrating with.

• Is there a client test system that has recent data. This is often a major obstacle to get good test cases.
• Is there a non-production system to test with?

Documentation

If you are developing a web service for a client, the documentation can be extremely important for the client developers. You should document the oddities of the web service that things like schemas do not begin to be able to approach. This might be things like “cascading” prompts and interrelated fields.

Code Reviews

Many large organizations have formal and informal code reviews. These take time but generally don’t get in the way of development other than getting them scheduled. You need to be sure you account for this in your timeline.

Move to Production

The actual move to production can take a few days to get done and coordinate especially if your organization has strict change control procedures.

Development Estimate

When you are creating web service, the question is always asked: How long will it take?

This is an important planning question. The answer depends on man factors including:

• Your level of expertise with web services.
• Your expertise with PeopleTools and web service in PeopleTools
• Your business knowledge of the problem being solved for.
• The complexity of the web service and business process.

First let’s assume the deliverable is a web service with medium complexity which may combined a “GET” and an “POST” (update). I put together some rough timelines in the amount of days it might take for a beginner, intermediate and expert to get that done.

These numbers should give you an rough estimate of start to finish web services. I have seen these come in way over and way under this depending on many factors.