Help Center>Foundation Help

Applies to:

Solution development best practices

5. Develop the solution

Solution development best practice guide

  1. Build a development team
  2. Start the discovery process
  3. Build a proof-of-concept
  4. Gather requirements
  5. Develop the solution
  6. Support and maintain the solution

Once the requirements have been approved and frozen you can begin development. Because multiple developers may contribute to a solution, it's important to use a sequential process for development.

On this page

  1. Build scripts. (if you are integrating with SAP).
    If you’re building a Solution that integrates with SAP and uses Winshuttle Transaction/Query scripts, the scripts are the foundation of the form. They must be created and tested prior to developing the workflow and form.
  2. Build the developer view.
    Create a Developer View in the form to serve as a master view that holds the entire entire form contents, including all rules and calculations required for the Solution.
  3. Build the workflow.
    Develop the workflow after the form, because dependencies in the form drive the workflow.
  4. Create form views.
    Once your form is completed and the workflow has been tested, you should know how many form views you need to create, and the workflow participants(s) (i.e user or group) for which they will be displayed.
  5. Test the solution.
    Test the solution with a group of users to ensure everything is working correctly in the form, scripts, and workflow.

1. Build scripts

If you’re building a Solution that integrates with SAP and uses Winshuttle Transaction/Query scripts, the scripts are the foundation of the form.

Scripts must be created and tested prior to developing the workflow and form. Scripts should also be tested thoroughly before adding them into the Solution.

As each script is built, do the following tests:

  1. Test the Winshuttle script directly within Winshuttle Transaction or Query using Microsoft Excel.
  2. Save the Excel mapping in case of issues later in the process.
  3. Convert the mapping Source Type of the Winshuttle script to XML and test within Transaction or Query .
  4. Create a very simple form and workflow with each Winshuttle Script. Run the script directly in the form to make sure the script is working properly.

These tests will help ensure any features being used in Winshuttle Transaction or Query are going to work within a form or when running with the XML source type.

If a problem with a script is identified during the testing phase that requires an additional script or modification of the current script you can still do it—however, whenever possible avoid regenerating the form to keep everything correctly mapped.

2. Build the developer view

Once you have the completed building and testing scripts (if you are using them), you can begin developing your form.

Winshuttle recommends first creating a Developer View in the form to serve as a master view that holds the entire form contents, including all rules and calculations required for the Solution. This gives you a single form view as your baseline, and makes it easy to later create additional form views.

Once the Developer View is completed, test the form with a small group of users and verify the following:

  1. Scripts are running and mapped to the correct fields (if using Winshuttle scripts).
  2. Calculations, rules or any other business logic within the form works correctly.
  3. The form layout or style is correct.

Initial testing should be completed before creating additional form views. Issues discovered after all the form views are made take longer to correct because you will have to update all of the form views. If you discover a problem prior to building additional views, you only have to update a single view.

Additional information

Form design tips and best practices
Read more tips to help you streamline your form development.

3. Build the workflow

After the Developers View has been created and tested, you can begin workflow development. Sometimes workflow development is handled by someone other than the form developer, but typically form and workflow development are done by the same person.

Develop the workflow after the form, because dependencies in the form drive the workflow. In addition, you’ll gain insight into the number of views your form will need, and what each view will show. For example, if you had a workflow that routes according to field values in your form, you can’t configure these in the workflow until the fields exist.

Once the workflow is finished, you need to run a few basic tests prior to creating the form views. The tests are heavily dependent upon how your workflow is built and how you route your form., but some generally recommended tests are described below.

Recommended workflow tests

  • Make sure the correct participants are being assigned throughout the process. If you are using a Participant Resolver, make sure the query is returning what it needs to assign tasks.
  • Test all routes for the workflow. If your workflow is being routed based on form data, make sure those field values are being populated.
  • Make sure all notifications are being sent and they are being received by the assigned participants.
  • If you are using any plugins in your workflow, make sure they are running the correct operation(s) with expected result(s).
  • Test loops. Make sure all loops exit when they are supposed to.

While running these tests, also consider how errors will be handled. If there’s a possibility for something to go wrong in the workflow, there are Transition properties such as ‘IsAssignmentValid’, or ‘Otherwise’ that are great to use to prevent the workflow from encountering an error.

See Composer Transition Properties for additional information.

4. Create form views

Form Views are the last step in the development process before testing the solution. Once your form is completed and the workflow has been tested, you should have a thorough understanding of how many form views you need to create and the workflow participant(s) (i.e user or group) for which they will be displayed.

Winshuttle Composer has special, predefined and reserved Form Views (see table, below) that can be used for given scenarios. You can not have more than one view with the same view name, but you can create and name your own form views as needed.

Winshuttle recommends as a minimum to always use the Originator View and Process Completed View.

See Working with Composer views for additional information.

Winshuttle Designer/Composer predefined form views

Composer View

Description

Originator View

This view is rendered when the form is first launched by the Originator.

ReSubmit View

This view is rendered when the form is resubmitted.

Process Status View

This view is rendered when someone wants to view the form but does not have an outstanding assignment.

Process Completed View

This view is rendered when the process is finished.

5. Test the solution

Once development is completed, it is time to test your solution with a group of users to ensure everything is working correctly in the form, scripts, and workflow. This often requires creating specific test cases to use for testing.

Be sure to maintain open communication channels with your users. As issues surface throughout the testing process, Solution Developers must continue working with end users to fix them.

Note that testing and validating a solution should not generally be used for users to request additional functionality or features. However, if new features are added at this stage, the testing process must be extended before the solution can be moved to production.

Once testing is completed for the solution, begin planning the migration of the solution from the development server to the production server. Typically, migrating a single solution takes 1 day.

Test the solution after migration

Upon successful migration to production, you should allow for someone to validate that the migration was successful by checking on any dependencies. Things to check after migration are:

  • Do the Winshuttle scripts still function correctly?
  • Are the Winshuttle scripts running against the correct SAP system?
  • Is the form routing correctly?
  • Is any form/workflow logic broken or missing information (ie: drop down lists)?
  • Are Email notifications being sent out?
Additional information