Development Best Practices

Development Best Practices


  • When developing ANYTHING make sure the performance is acceptable.
  • Plan your performance optimization based on the POSSIBLE number of records that can be processed. Your test may be fine for 10 records, but what happens if there’s 1k+?
  • Try to avoid doing process heavy things in the On-Load process of a list section. Eg calling a BSFN.
  • Always see if there’s another way to do it (like a value transformation / javascript) before resorting to a List Section Onload
  • Combine JDE BSFN calls into one Service call whenever possible. Initiating a BSFN connection adds time to the BSFN execution. If this is in a single call, it reduces the connection overhead.
  • Be careful with this one as there is a limit for how big of a XML string we can send to JDE.
  • If you hit this limit, you may need to process the requests in groups of X records a time.
  • Combine SQL queries into as few as possible
  • Example: If a query is in a for each loop, try to take it out of the loop and run a single query with an “IN” instead of 1 query per record.
  • You can also use UNION separated queries
  • This is often done when querying an order history table and an archived order history table (in JDE, F4211/F42119)
  • Be careful with parameterization on this one since SQL has a ~2100 parameter limit
  • When you expect the two queries you are unioning to have no records in common, use UNION ALL instead of UNION. A regular union tells SQL to not return duplicate rows.
  • For-Each loops
  • Use Temporary WorkData services whenever possible. These load the results that you will be looping on into a hidden and temporary WorkData. As records build up in the usual WorkData, actions performed against it are slowed down. By using the temporary WorkData, this slow down is avoided.
  • Only do necessary actions inside the loop
  • Try to use XSLT for each loops instead when possible. These are also more efficient because they don’t produce logs.
  • SQL Query optimization
  • Make sure to join and filter on primary keys or indexes of the table.
  • Use as many as possible. The SQL pre-runtime optimizer will run your query in the fastest way possible based on the indexes you’re using in the query.
  • When creating a SQL table, it is your responsibility to create SQL indexes on fields that you will filter on (outside of the primary key) to keep performance optimized.
  • If a JDE query needs an index, see if it is a realistic scenario to add the index.

Naming Conventions

Follow standard naming conventions when creating elements. Proper names help keep associated changes together and communicates to future developers what was done or how something should be used. Below are some examples.

  • Database and Table names
  • Prefix table names related to the same feature with the same string so they appear next to each other in SSMS. For example, tables related to items for EASYCommerce are prefixed with “EC_Item_”.
  • Process
  • The name you give a process should describe the functionality of the process. The idea is if you search for the process in EASYProcess’s Work With Processes, that your process should come up in the results.
  • Webpart
  • Some webparts related to the same feature have a prefix. If you are working on a feature following this naming convention, continue using this so they all are returned from a search against that prefix in the EASYProcess Work With WebParts screen.
  • Page
  • The page name becomes the primary key of the CMS_Page entity, so choose a name that reflects what it will be used for.
  • Workflow
  • API
  • Give your Source Control Management (SCM) Project a proper description
  • Often, projects that are not ready for Production site in the promotion path for weeks or months. The project description is the best place to document what your changes are related to. This helps future developers.
  • If you are using an issue tracking system, name the project with the reference to the ticket id. If you are using an issue tracking system and the SCM project doesn’t have a ticket in the tracking system, create one.
  • Name Process Services properly
  • Binary Decisions
  • Services
  • For-Each Loops
  • etc.

Sharing Sources in SCM

If multiple developers are working on an application at the same time, it is likely both developers will need to work on a single source. It is important that the two developers work together to coordinate their changes without negatively impacting the application.

If you find the source you need is checked out by another developer, you have three options:

  1. Entirely promote the previous change through to PD so you can start fresh with yours.
  2. Your changes may become coupled with their changes. Both Projects need to move through SCM promotion path together.
  3. Your changes may need to be put on hold.

Follow the below steps to identify how they should move together through the promotion path.

  1. Find Out Why the Source is Checked Out Already

  1. How this Helps

  1. This will help you identify the priority of their fix. A customer-impacting bug fix would have a higher priority than a planned improvement with a far out release date.
  2. It may be the case that their change is no longer needed and you or them can “Undo Checkout” which releases the source and enables you to begin your changes.
  1. Where to Find Information

  1. If the other developer is available, ask why they checked out the source
  2. Read the Source Control Management (SCM) Project name for clues. If the other developer has named the project with a reference to an issue tracking system, refer to the associated issue for more information.
  1. Find Out What has Changed in the Source

  1. How this Helps

  1. The previous developer’s change may alter your planned design for your change. It is important you both are on the same page about how the source should function and its supported features.
  1. Where to Find Information

  1. If the other developer is available, ask what they have changed in the source.
  2. If you were able to find an associated issue in an issue tracking system, scan the issue for developer notes of changed sources.
  3. Open the source in the Production environment and compare to the changed source. The change may be large and obvious. This approach is more difficult if it is a minor change.
  1. Determine if the Previous Change is Ready to Move to PD

  1. How this Helps

  1. If the previous change cannot be discarded (Undo Checkout), you need to determine how far it can be promoted. The blocker on this change now becomes a blocker on your change. This may affect your timeline and you need to be aware of it.
  1. Questions To Ask

  1. Has it Been Tested by the Developer (Unit Testing)?
  1. The first step of development is unit testing by the developer. If the feature is not even tested by the developer, this tells you development is not done.
  2. Follow up questions would center around when the development was planned to be completed.
  3. If the development is on hold with no date scheduled, it may be better to revisit discarding the changes.
  4. You could also pick up development of both features and test and move both through to the promotion path together.
  1. Has it Been Tested in QA (System Integration Testing) by the developer and someone else?
  1. The first step is for the developer to test in QA. Once it has passed the developer’s testing, it should be tested by someone else.
  2. If the change is missing its second tester, you could test it to approve the changes. In this scenario you would be helping the previous change to move all the way through to PD so you can start fresh with your changes and no previous dependencies.
  1. Once it is fully tested and ready for Production, does it need approval to move through to PD? If so, does it have that approval? Does it have a release date?
  1. You may be able to promote the previous change all the way through to PD, but its important to remember who needs to sign off on the release to PD. If you have that approval, moving the previous change through to PD may unblock your development.
  2. If you don’t have that approval or a release date is set and it can’t be moved earlier,  the previous change may need to be completed before yours can begin or you may need to couple your changes together and move them through the promotion path together.
  1. If It Were Ready to Move to PD, What Needs to Go With It?

  1. How this Helps

  1. If you are able to entirely promote the previous changes, you want to make sure the promotion includes all needed changes.
  1. Where to Find Information

  1. If the other developer is available, ask why they checked out the source
  2. Read the Source Control Management (SCM) Project name for clues. There may be another closely named project that mentions a dependency.
  3. If the other developer has named the project with a reference to an issue tracking system, refer to the associated issue for more information. If a feature or bug fix is ready for production, developers will often attach deployment notes to an issue.