3 Understanding Projects in JD Edwards EnterpriseOne OMW

This chapter contains the following topics:

3.1 Understanding Default Projects

This section discusses:

  • Default projects.

  • Roles in default projects.

3.1.1 Default Projects

When you run JD Edwards EnterpriseOne OMW for the first time, the system creates a default project and tags it with your user ID. The default project is your personal project that you can use for development and research.

You can use default projects to do the following:

  • Develop objects that are later moved into a regular project.

  • Store objects to be added to a project later.

  • Automatically store objects worked on outside of JD Edwards EnterpriseOne OMW.

A default project is similar to a project except that the project status of a default project never changes. Therefore, you cannot use a default project to transfer objects.

Non-Object Librarian objects can be accessed outside of JD Edwards EnterpriseOne OMW. If you access objects such as versions, user defined codes, menus, or the RDA outside of JD Edwards EnterpriseOne OMW, these objects are added to the default project. Any changes that you make to these objects must be tracked and managed through the default project. Modifications to non-Object Librarian objects are always logged.

If you want to advance the status of an object, use JD Edwards EnterpriseOne OMW to move the object from the default project to a project.

3.1.2 Roles in the Default Project

Although your default project appears immediately, you have one role only (usually Originator), as configured by your system administrator. You might need to add yourself to your default project in another role, such as Developer.

3.2 Understanding the Lifecycle of a Project

This topic discusses a typical project lifecycle from inception to completion. It includes steps required by a SAR-based (software action request) system. If you are not using a SAR-based system, some of the following steps might not apply to you. Furthermore, depending on your business's software development procedures, the steps that you follow and their order might vary from the following process.

  1. Based on the task to be accomplished, create a new project.

  2. Add users to the project.

    When you add a user, you define the role of the user, based on the actions that you want that user to be able to perform within this project. You might need to add a user more than once if you want the user to be able to perform actions allowed by different roles. As the project progresses, you can continue to add (or remove) users as required.

    When you create a project with SAR integration turned off, you are automatically added to that project in the role determined by your system administrator (usually, as the Originator). You might want to add yourself to the project in other roles as well.

    When you create a project with SAR integration turned on, the person who entered the SAR is added to the project in the role of Originator.

  3. Add objects to the project.

    Qualified users might be adding objects to the project throughout much of its lifecycle.

    If you create a new object, drag and drop the object from your default project to the project as appropriate.

  4. Check objects out and in.

    To be able to save your changes to an object, you must check the object out, apply your changes, and check the object in.

    You can check out an object only if no other projects hold the token for that object. If the token is available, it passes to your project when you check the object out. If another project already holds the token for the object, you can join a token queue to be notified when the token becomes available.

    After checking out an object and modifying it, you can save your changes without checking the object in.

    When you check an object in, the system will not release the token from the project. As long as your project holds the token, another qualified user in your project can check the object out, but users in other projects cannot. You can enable users in other projects to check an object out by removing the object from the project.

  5. Advance the project.

    As the project progresses through its lifecycle, you must change its status. You do this by advancing the project. When you advance a project, the allowed actions for some roles might change and some objects might be transferred to other locations. Status-based role changes and transfers are configured by your system administrator.

  6. Complete the project.

    Based on your processes, you might archive or delete the project when finished. In JD Edwards EnterpriseOne OMW, 01 (Complete) is a closed status.