Workbench Toolkit
Our Workbench can be viewed as a one-stop location for the Technical Project Manager, Upgrading Developer and the QA Tester during and after an upgrade.
It comprises a suite of applications that delivers the following value by role:
- The Project Manager’s role is critical to the success of the upgrade project. They will need to co-ordinate and direct resources to ensure that quality standards and timescales are being met.
This enables the PM to divide the upgrade effort into logical task based units using the hierarchy within the Workbench.
The PM is able to allocate developer and QA resources against tasks and set due dates etc.
Using the Object Statistics application, the PM can easily view an objects size and complexity. They can then assign the most appropriate developer for the job and set more realistic timescales as a result
The PM will be able to track time spent on tasks and objects against estimates. They will be able to view a tasks history to view the number of QA re-works etc
The PM will have ultimate control of what tasks and objects are released for OMW project promotion to the UAT team etc
Project status reports will be available to the PM so that they can report to senior management on progress
Testing issues and resolutions can be recorded by the QA Tester and the developer to ensure that communication is transparent to all.
- The developer must ‘uplift’ the agreed modifications and ensure that they function as expected under the new release. This is a key task in any upgrade and the developer will perform to their optimum with the following tools.
- Allows side-by-side (text based) comparison of all E1 object types even if Form, grid or report variables have been renamed
- Our .dim files show you exactly where the changes are in the modified objects. This significantly aids the upgrade process and bypasses the need for Visual Compare. It also bypasses the need for frequent check-in’s and out’s, constant time-consuming snap-shotting between releases or even having two machines on the developer’s desk!
- Automatically identifies many of the common upgrade issues such as corrupt IF statements, obsolete functions and tables and many more
- Allows the developer to use the powerful Dimension X-Ref application. The Standard JDE Cross-Reference build takes many hours (even days) to complete and it includes much information that is irrelevant to upgrading developers. Dimension Cross-Ref is a much faster process that allows developers quick and efficient access to more detailed and specific upgrade-related information.
Unlike the standard JDE “one object at a time” enquiry, Dimension X-Ref provides the ability to search within a tree structure, so the developer can drill down (and UP!) as many levels as they wish (on-the-fly) to determine the objects used by a given object, or indeed the objects that use the given object. For example, within seconds you can determine the object(s) that call a specific BSFN. As you keep drilling up through the “tree”, you can quickly and easily reach the top-level object to determine the originating source(s) of the transaction.
With Dimension X-Ref you can also search using UDC tables, Data Dictionary items, DSTRs, TBLEs, Table Indexes, Proc Option Templates & Business Views. So determining all objects that use, say, a custom Data Dictionary Item or Error Message or custom index in a standard JDE table is simple.
Dimension X-Ref automatically includes all called/calling elements, including standard-JDE elements, but to enable even faster navigation, the developer can set a checkbox to simply hide/ignore standard JDE items, revealing only custom objects and their usage. During an upgrade (and also on-going system support) this form of cross-referencing can offer many advantages.
- The developer can record time spent at the object level
- Issue problems and resolutions can be recorded by the developer at an object level
- The developer can reference back to the original extract results. During the upgrade, a developer may come upon an object that does not appear in the “to upgrade” object list, which represents an anomaly in the planning process. Using Dimension, the developer can quickly access the Client Extract Include List application to determine why the particular object wasn’t included. Perhaps it wasn’t found at the time of the extract. Perhaps it was deemed a “hack/test” object that was dropped from the list. It may be a UBE that was thought to be unused (owing to a very old “last ran date”). There are many reasons why an object can be excluded, but Dimension provides the answer, and possibly a solution/improvement in the upgrade (if, for instance, a UBE called from a report exit on an application is never used, then why not drop the UBE, the application’s report exit and supporting logic altogether?).
Another example may be to look at objects with non-standard naming conventions. Looking at the extract results will tell the developer that these objects were considered. There may also be notes alongside the object explaining reasons for its non-standard name and whether that name should be retained or replaced during the upgrade.
- During the upgrade, the developer constantly needs access to the old code. Looking at it in the old release provides “context”. If you have access to the old release code from the to-release you may be able to use VC (but with all the inconsistencies and delays that incurs) or you have to exit the to-release, snapshot out and into the from-release, sign on, go to OMW and view the code, make notes or print the logic, exit from the from-release, snapshot back, enter OMW and make the desired change, only to realise you forgot to look at a field’s properties and you have to start all over again (been there, done that). This is why for die-hard dedicated upgrading developers having two physical PC’s on their desk is often the preferred solution. BUT, if you have the .dim files you can access ALL the information from the from-release object (and PRIST side for differences too if req’d) in a separate text based window without having to leave your to-release session. You can remain in the design tool. It is much, much quicker. It’s also a potential saving of hardware cost, not only time.
- Access the detail to see/confirm if Dimension has deemed a mod as containing only “layout” type changes, for instance. Sometimes it’s nice to get this reassurance – “have I missed something in this object” is a constant concern to upgrading developers – this helps to alleviate that concern.
- Determine if a table may have received a possible DD definition change
- From the “stats” you can currently drill down to the index usage and also to see what hooks to standard and their complexity have been recorded by Dimension
- See if any client-only BSFN’s are called by the object.
- Are any called objects unknown or missing?
- Determine the extent and type of Version Overrides that apply
- Access the name of the “based on object” for copies of std objects
- The QA Tester must ensure that the upgraded modifications have retained all the functionality that the users experienced in the old release. The QA tester must be able to interact with the Project Manager and Developer in a way that is transparent to all. Using the Workbench will ensure that the User Acceptance Testing (UAT) runs as smoothly as possible.
- The QA Tester can reserve and lock objects for testing
- Ability to record testing results against a task or an object
- Ability to change the status of an object to reflect testing results etc
- Can also see the dim files for full detail
- Ability to record QA time spent against a task or object
- Ability to access automatically generated upgrade issues for an object