SMP 3.0: Agentry - Best Practice for transporting Config Panel and Java changes.

[Former Member]

All.

I am looking for a way to perform transports in a productive SMP 3.0 Agentry environment with the following characteristics:

• You want to have as little downtime as possible.
• You want to have a fixed procedure for doing transports.
• You are performing frequent changes to the Agentry solution (incl. Config Panel and Java Coding).

Suppose we are introducing a new Java Class for an existing Fetch procedure, which interacts with an new (SAP) object class.

The new Java Class would require new parameter values in [BAPI_CLASS] and [BAPI_WRAPPER] of the Config Panel.

The new SAP Object class would require a new parameter value in the [SAPOBJECT].

For both of our classes we would create subclasses which inherit from the existing SAP standard Java classes.

If the ABAP customizing transport is moved to production before the Java Classes of Agentry, we would have runtime errors, because classes not present in the JVM would be attempted to be instantiated (dynamically).

If the Agentry environment is imported before the ABAP customizing, then calls of new methods of the SAP object class, implemented in our new class, will cause runtime errors because our new class will not be instantiated dynamically, due to the missing configuration in the Config Panel.

Hence, Config Panel changes and Java Code must (in general) always be imported simultaneously.

In our company, the transport procedures does not always ensure, that we have full control of when exactly ABAP imports are performed.

Therefore I am looking for a general procedure for being able to import ABAP and Agentry changes independently and still maintain usability of our solution.

Does anybody have some good ideas on how to achieve this ?

Thanks,

Søren Hansen

[bill_froelich]

Søren,

As you mention, this is a challenge for many types of applications that have dependencies on other systems and components.  The scenario you describe is what I refer to as a "breaking change".  Something where the changes you are introducing may break existing functionality.

Since you say that you don't have control of the transport timing, you may need to take extra steps to ensure things don't break.

In these cases, one option is to create new methods so that rather than modifying the existing fetch for example, you create a new fetch instead that will exist in parallel with the current one.  It can of course start with a copy of the existing fetch code under a new name.

This will allow for the transport to be propagated to the next environment without impacting the operation of the existing application.  Once you have confirmed the transport was applied correctly to the new environment, you can then schedule the update to the application / java knowing the transport is already in place.

It does involve some extra work but is something to consider if you really can't control the transport timing during a production deploy / rollout.

--Bill