SAP Library - Find your answers

1. A request for a change is submitted to support team
2. Change is done in DEV (if approved) and tested by support team (limited testing only due to lack of productive data)
3. Change is transported to TST
4. User testing takes place
5. User approves or rejects (giving reasons)
6. System manager approves the change to go into PRD
7. Change is transported to PRD

All transports are done by the support team. If a change is urgent it is transported straight away, if not they are batched up and done once a week. The Workflow can be controlled by a software like a Lotus Notes database so you can have a record of approval at every step.

Note :-
The system manager is the manager of the support team. The system "belongs" to him i.e. it is his responsibility and he has the final say on what goes into the PRD system. 99.999% of the time he will approves the change, this is mainly a way of keeping him informed of what changes are happening in the system.
Many companies uses the core modules MM, PP, FI, CO. The problem with transporting single transports is that if it is a program, the complete program buffer is reloaded therefore giving a performance hit. Therefore you tend to leave them and just have one performance hit per week (although most weeks there are no program changes). When you are in production the number of transports will settle down to a reasonable figure. Maybe about 10 transports a week, and most of those are material groups (which, although they are user data, they are classed as customising). This rises if you are doing any modifications or changing business processes etc, but 10 is about quite normal for most.

SAP Business Workflow – Advanced Programming with ABAP OO

As Workflow moves towards ABAP OO programming to enhance and eventually replace the Business Objects, this is becoming a must for all workflow consultants and developers.

This is presently a one day course to be taken either by experienced workflow consultants or, in addition, by those who have attended the BIT610 standard workflow programming course.

The course is run on Web AS 6.20 and has the following prerequisites: BIT600, BIT601, BIT610 and BC400 & BC401

• Identify all points in the workflow system at which programming is possible or necessary.
• Create your own classes and use them in the workflow architecture
• Use Container Parameter Interface as the new application programming interface (API) for workflow related functions (check, receiver type, and so on)

• Creating a Class with Instance Handling
• Creating Attributes for Workflow Class
• Creating Methods for Workflow Class
• Creating Exception and Event Handling for Classes
• Creating and Test Workflow Functions with ABAP Classes