Skip to Content

If Yan can Cook… Yan Could Code… (SAP NWDI Part III)

If Yan can Cook… Yan Could Code… (SAP NWDI Part III) Part III – Is it really just like making a Pizza? Welcome to “If Yan can Cook… Yan Could Code… (SAP NWDI Part III)”. If you would like to go back and start this series from the beginning please follow this link: If Yan can Cook… Yan Could Code… (SAP NWDI Part I). So in the previous entry to this series I discussed and explained in my own special way how one could perceive the NetWeaver Developer Studio environment as your own private kitchen to cook in. I also helped you look at the NWDI in a pretty different way. Now I will move forward in the next entries in the series to show you how NWDI also acts as everything from your recipe/ingredient/utensil library/pantry right up to your packaging and delivery method. If you have stuck through my unique writing style and viewpoint on development this long, you obviously have a lot of free time to kill during your current SAP upgrades. Now then, what exactly are these development objects? They are basically items that are stored in the DTR (Design Time Repository). They are versioned files that live within the source. To be more descriptive in my definition of these objects they are really just a JAVA source file, a WebDynpro View or perhaps a table definition. They are essentially the recipes and ingredients that are available in your Library and Pantry. From these humble and simple objects within the DTR you will be able to put together your Development Components that will make up your finished meal (The Software Component(s)) that will eventually be put out for the Delivery Guy (the JAVA Transport) to be delivered to the consumer. Maybe even in 30 minutes or less. Just like that Pizza place. Development Objects (Do’s) let you know what to do with your Development Components (DC’s). They make the DC’s all go together nicely and work together to form a strong cohesive final product. The DO’s as I stated before could be libraries, source files, views etc. So in fact in your kitchen they could also be the phoned in pizza orders for any given Chef to cook up. Now you can kind of see where I was going with the multiple Swedish Chef analogy in Part II. In a large pizza place there are going to be multiple chefs tossing pizzas. They will all be using the same NWDI for their recipes, orders, resources, compiling, staging and ultimately for deliveries. For example: Let’s say that the pizza orders (DO’s) are all put together with various ingredients (DO’s and DC’s) on the assembly line of various pizza chefs. The chef will take the ingredients that they need and start to put them together to make up their DC’s or in this case pizza. Some of the items that will make up their DC’s have already been pre-made by another chef so the chef preparing the order can check out these ingredients; use what they need in their new DC’s and leave the rest for other chefs to use in the future. The chef will take a stainless screen and place it on the work counter. We should view this stainless screen as part of the toolset that is available to you in the NetWeaver Developer Studio. It is the template that the chef will use to put together the pizza order on. This template will take all the ingredients listed in the DO and allow them a place to be put together so that they can later be checked back into the DTR or “pizza oven” were they will be compiled and later error checked at the time of packaging. We need to look at what goes on the stainless screen template for a moment. All the ingredients are very specific to the finally outcome of the order. The chef takes a piece of dough, kneads it out to fit the screen and then starts placing all the other ingredients onto it. He starts with the dough, then the sauce, onions, pepperoni, garlic, spices and then cheese. You could easily transfer this to a developer mindset in the sense that the developer will open up Developer Studio (The Kitchen), choose a template (the stainless screen), checkout the needed views, JAVA source and libraries (ingredients etc.). The developer will then start putting together the Development Component that they are responsible for in their project. This could be a shopping cart or a simple end user table view for specific data like say order entry or a product view. When the developer is done developing on the template that they have chosen to code they can then check it for errors on the fly and make sure it does what they need it to do. At this point they can check it back into the system to be check against the other DC’s or SC’s in the DTR for compatibility. I compared the DTR to an oven earlier because it is important that everything that all the chefs are working on fits in one oven harmoniously and without error. If a chef or developer changes a recipe, a DO, a DC or a SC they can go ahead and saved it as a new recipe or version. This is very important as it will keep the integrity of the recipe database/DTR. No one single Swedish Chef will have control over the entire environment to potential destroy another Chefs recipe, ingredient or library. Continued: Part IV – Box it up and Deliver it
You must be Logged on to comment or reply to a post.