Skip to Content

Once upon a time,
not so long ago, there lived a Developer who worked for a software firm called
Chaotic Systems.  The process of software  development in this firm was
error-prone and, in many ways, sub-optimal.  The Developer didn’t realize it
then; being a newcomer, he was inclined to attribute mistakes to his own
carelessness rather than think about whether the systems he worked with
helped him do his work in a manner that was less error-prone, and whether the
tools he used enhanced his productivity.   

A picture from
the past

The application

they were developing was COM based, and to set the right working environment

they used to copy the binaries ( .dll and .ocx files ) of all dependent

components from the build machine to their local machines and ‘register’ them.

The project was a large one – they had a number of inter-dependent components –

and typically all of these had to be taken together, because the

dependencies were not always clear ( they had to be manually extracted by

looking into the project definition of each component ).  There was a batch

script to perform this task  (of un-registering the old components, copying the

new and registering them ), so even though this had to be triggered manually (

outside the IDE ) this was not much of a problem.  

Finally, the

Why DTR ? Why not Perforce or ClearCase…?. The server of SCM tool was located in

their head office, and hence the sync of sources was extremely slow. And he

always had to do double maintenance for the fixes he made in the code lines (

branches ) of earlier releases. ,

he only needs to ‘Create a Project’.  The tasks typically needed +before +

creating a project – like synchronizing sources from the repository, getting the

archives ( binaries ) of dependent Development Components from somewhere else –

is done automatically by the SAP NetWeaver Developer Studio.  It contacts the

right systems in the landscape to get the sources and archives.  The Developer

also sees that the archives of only dependent Development Components are

fetched.  From the documentation he finds out that this is possible because

dependencies between Development Components are declared explicitly, as defined

by the

SAP

Component Model

After making some
changes, the Developer triggers a local build of his Development Component,
using the SAP NetWeaver Developer Studio. He then notices that a special
component – a

Build Plug-in

– is available on his machine, and that
performs the local build of his component.   

Satisfied with
the successful local build, the Developer does a ‘check-in’, which checks-in the
changes into the

inactive workspace

of his “development” code line .
After a check-in, the SAP NetWeaver Developer Studio asks him if he wants to

activate

his changes. He chooses to activate, and this triggers a build of
the Development Component on the central

Component Build Server

( CBS ).
He learns that in the background, a lot of things happen at this stage : if the
build is successful, the CBS stores the newly built archives of this Development
Component into its archive pool, and also triggers an “integrate” of the change
into the

active workspace

of the code line by sending a request to the

Why DTR ? Why not Perforce or ClearCase…?( DTR ), where the sources are located. 

This separation
between inactive and active makes the Developer realize that he can safely
check-in his intermediate changes and share his partly complete work with other
developers in his team. This will not cause any build failures, since sources
that lie in the inactive workspace are not built centrally unless a change that
was checked-in to this workspace is explicitly activated.   

After successful
activation, he informs his colleague – who is waiting for this fix – that his
modification is now available. That colleague syncs the Development Components
he depends on, and gets the newly built archive ( containing the fix ) from the
archive pool of CBS. So the colleague does not have to wait overnight for a
binary ( archive ) containing a fix he needs. 

The time soon
comes when this Developer has to create a new Development Component of a
specific type – Java.  While creating it from the SAP NetWeaver Developer
Studio, he wonders if he will have to write some build scripts to get this
Development Component built. He soon realizes that this is not necessary : the
Build Plug-in that builds Development Components of type Java is automatically
downloaded to his machine when he chooses to create a new Development Component
of type Java. 

When he adds a
class to this new Java project, he gets a popup asking him if he would like to
add this file to source control ( into DTR ). He chooses ‘Yes’, and that results
in the class getting added to an

activity 

in DTR.  This prevents build
errors occurring due to missing files caused by users who forget to add new
files into source control. 

After successful
check-in and activation of this new Development Component into the “development”
code line, he decides to consolidate his change into the “consolidation” code
line. To do this he chooses to

release

his activity, from the SAP
NetWeaver Developer Studio. This places the activity into a queue, and an
administrator monitoring this central queue imports it into the inactive
workspace of the “consolidation” code line using the

Change Management
Service

( CMS ). If the import is successful, the CMS triggers the
activation of this change in the “consolidation” code line, followed by the
deployment – through the

Software Deployment Manager

( SDM ) –  of the
Development Component into a central test system.  

After some days,
the Developer gets a mail stating that his Development Component is “broken” –
that is, the build of this Development Component ( which was automatically
triggered by CBS because an interface it used from another Development Component
had changed ) had failed.  Since someone else had modified an interface he used
in his code, he now has to adjust his code to the modified interface. Using the
SAP NetWeaver Developer Studio, he syncs this Development Component and all
dependent Development Components. This results in the download of the latest
archives of the dependent Development Components to his local machine. He sees
that a Development Component he uses has modified the signature of a method, so
he makes the change to use the new signature, checks-in his changes and
activates it. The activation succeeds, and his Development Component is no
longer in a “broken” state. 

Some months
later, he begins work on a new release. For this, his Quality Manager informs
him that he should use a new Development Configuration ( “Dev 2.0” ) . Using the
SAP NetWeaver Developer Studio, he imports this new Development Configuration
and begins work ( Behind the scenes, the SAP NetWeaver Developer Studio +could
+be connected to a completely different set of systems – DTR, CBS etc –  for
this new release, but for the Developer this is transparent ).  After a while,
when he has to make a fix in the older release, he simply opens the other
Development Configuration ( “Dev 1.0” ), selects the appropriate Development
Component, creates a project and makes his change. The switch in context takes
nothing more than a few clicks in the SAP NetWeaver Developer Studio.  He also
sees that since DTR supports integration of changes in both directions, he does not
have to redo this change in the new release – it will automatically get
integrated, and if it conflicts with a change he has made in the new release, he
will have to merge the two. 

Thus, our
Developer, happy with the enhancement in productivity JDI has brought in,
ponders over the fact that things have really changed since times in the past.
The infrastructure has evolved, and that helps him work better today, making
fewer mistakes and spending lesser time on house-keeping tasks.  ( Not all
developers are as reflective as our Developer here – most of them do not notice
the huge infrastructure backbone which aids their work in the background. This
probably speaks highly of the infrastructure – if nobody notices it, doesn’t it
mean it is doing its job well ? ). 

PostScript :
the bottom line

What does this
story of evolution mean for our customers ?  Apart from the obvious advantage
that the quality of applications they buy from SAP would be a few notches higher
thanks to all this infrastructure support, our customers also will get this full
fledged infrastructure to make use of.  While this is clearly an advantage for
big customers who have large teams that customize the products they buy, an
infrastructure of such a scale seems like an overkill for smaller customers. The
overhead involved in setting up and maintaining this complicated landscape is
something these small customers would clearly like to avoid. 

JDI addresses
this by supporting multiple

scenarios

, based on the requirements of
customers and on their existing infrastructure.  From using only DTR to version
their files in a small project, to using the complete infrastructure to manage
their landscape, these well documented scenarios address the requirements of
customers in different segments.  Further, there are migration paths available
to move from one scenario to another. 

Finally, a few
words about naming. Although the name  “Java Development Infrastructure” conveys
that the infrastructure supports development of applications based on Java, this
notion is not wholly correct. Development using JDI relies on the SAP Component
Model, which is a model independent of technology.  Today, the types of
Components that are being built are based on Java; tomorrow they could be based
on, for example, .Net, or any other technology.   

To report this post you need to login first.

8 Comments

You must be Logged on to comment or reply to a post.

  1. A great article putting a lot of key components of the Dev Studio into a real world context. Well done!
    (0) 
  2. Former Member
    Yes, I know this dll-business. After 5 years of pain we got a collection of loosely coupled tools that helped to survive.
    Our major conclusions at that time: must compile and do automatic unit testing before submit, then nightly make and module integration test.
    Need problem tracking system connected with code management system so that management and development can track the status of each problem and development request in a range of versions and patches.
    Promised land ahead!
    (0) 
  3. Former Member

    This new format is horrible and the full articles are not readable…it appears to present only the few paragraphs.  Please change back to the SDN site format…UGH!!!

    (0) 

Leave a Reply