Test, Production, Development system – What are the differences?
With the provisioning of a Business ByDesign instance we usually are provided with an additional testing environment in addition to the production system. On top of this, partners can obtain a development system. But what are the differences and characteristics of the systems?
As implied by the name, the productive system offers all features of Business ByDesign. Developments should never be done in a productive environment, thus this is prevented from SAP and technically not possible. Only limited production fixes can be created for existing scripts. These production fixes should only be relied upon during one of the four quarterly updates when the test and production systems are at different stages and therefore installing a common patch from the test to the production system is not possible.
A test system differs from a production system in many ways. Various functions are restricted, the licensing model is different, and more is possible regarding developments.
Overview of differences:
- Sending emails
- Mass data runs
- System maintenance and copy
- Differences in development / forms
In a test system, automatic emails (the ones which are maintained in the customer and fine tuning) are not sent for typical business documents. For example, the supplier does not automatically receive an email when an order is placed. This is a useful behavior in a test system. It is possible to set a fixed test address in the e-mail settings within the fine-tuning, so that this function can still be tested in the test environment.
Emails, which are sent via a custom development, are sent without restrictions in a test system. If you do not want to send any e-mails from a custom development in a test system, you can simply check within the source code in which environment type the solution is currently running.
Mass data runs / background runs cannot be scheduled indefinitely in a test system, here the maximum schedule duration is 2 months.
From a production system a new test system can be created as a 1:1 copy, or an existing one can be updated with the data from the production system. Various items such as attachments can be excluded from such a copy. Details can be found in ByDesign’s built-in help (Search: EN: “System Request” DE: “System anfordern”).
After a copy, internal IDs of custom fields created via customization mode are also the same. This is relevant for forms and developments.
A test system is usually updated to a new ByDesign version about 3 weeks before the update of the production system.
The user licenses are based on the production system, so if more users are created in the test system for tests, then there are, as things stand today, usually no additional costs for this.
The creation of customer-specific developments and development in the test system is possible. In the development system there are additional functionalities, which are discussed in the next section. A special feature of the development in the test system is that there is an additional solution for the development of a patch. So, from version 2 onwards there are always two solutions, between which can also be actively switched. These have a different namespace, which means that, among other things, web services and the customer-specific fields they contain have a different prefix. There are also different data in the database for the customer-specific fields and objects between the original and the patch solution. Depending on the use case, this can either be an advantage or a disadvantage.
Generally, customers do not have their own development system. As far as I know, SAP partner status and trained developers are a requirement for the provisioning of such a system (I am not sure that this is entirely correct).
Since this information is now only relevant for developers, I keep it compact:
- No distinction between original and patch solution -> only one solution
- No customization mode available (not needed)
- BADI’s (Enhancement Options) can only be developed here
- Reason: Risk in case of errors, because of deep system intervention
- In the dev system there are not always LeadingZeros at ID’s, but in Test and Prod there are.
- It is possible to turn off the PSM check to see more information in the repository explorer.
- There are own customer areas within the system to order the solutions and so that solutions with different internal customer ID’s can be installed in one system at all (Administration -> Switch Customer)
- Possible dependencies in case of further development of the same development solution of another partner whose tenant is on the same server (example: sale of rights for a solution).
- Creation of Multicustomer Solutions is only possible here (together with SAP)
The sources on the subject are rare, I have tried to put my knowledge from my point of view and my work as a developer together to contribute a part to giving new consultants and developers a better understanding of this subject. A complete picture of this can only come from the cooperation of several perspectives. Thus, my question is: What other system differences have you encountered and would you like to share them with the community?
I'm an full time employee at a customer. We are running S/4 HANA on-premise. And I think you'll find most on-premise (even non-HANA) have a DEV. In my case this is not business by design.
DEV -> Test (QAS) -> PRD To the side of the transport path is SBX
DEV - the DEV client is where you change code/configuration and run some basic tests. When everything is working right you transport to test.
Test - Test is locked down. No development or config. changes. It is to test on a copy of data very similar to your PRD data. You may have to go to DEV and fix things and then transport to Test again. Customer tests are done in test. It is not exactly like PRD. But very close.
PRD - no changes except for allowed ones. Some allowed ones may be in configuration tables, query, and/or mass maintenance. Of course archiving is changeable.
SBX - is off to the side. It gets refreshed more often from PRD. It is usually used with "larger" projects or theories to test to make sure they are going to work prior to developing.
And.... There are always exceptions. Most third part software I've worked with usually only has test and production. That makes it a little challenging when it is an add-on and we have BADIs to change.
I believe we have the DEV -> test -> PRD set up for analytics on the cloud similar to a third party tool.
Enjoy - a different look at the landscape through a on-prem customer.