Page History

...

...

1. For any additional queries and concerns you can refer Example component. You will always find the code in example component to be the latest code of OFBiz. Take reference whenever you want to see some sample code for the development of this application, this will help you in future developments as well.
   Every new feature is first added in the Example component for the references.
2. Before starting the development of this application you must read the contents from:
   OFBiz Contributors Best Practices ,  Coding Conventions and Best Practices Guide
3. Don't copy any file from other component, as the revision number for the file is also copied. Always create a new file and, if required, then copy the contents of the file." Also be conscious about the unused code as well.
4. For searching any of the document the best place is at : OFBiz Documentation Index.
5. Right from the beginning, reading the console log must be a habit to make troubleshooting easy and understanding the system well.
6. You can find the source code of this application attached with this document that you are going to develop but it is preferred to just take reference from it. It can be downloaded from here: Download Source

...

1. Create a "webapp" directory in the practice component (hot-deploy/practice/webapp).
   This directory contains all the webapp related files for the component we are creating.
2. Create a sub-directory inside the webapp directory by the name of  "practice" which is the name of the webapp which you are going to develop (hot-deploy/practice/webapp/practice). A component can have multiple webapps attached to it. e.g. In the "marketing" component there are two webapps "marketing" and "sfa".
   The webapp we are creating will follow the J2EE webapp standards.
3. Create WEB-INF directory in your webapp (hot-deploy/practice/webapp/practice/WEB-INF).
   An OFBiz web application requires two configuration files, a controller.xml and a web.xml. The controller.xml tells OFBiz what to do with various requests from visitors: what actions to take and what  pages to render. web.xml tells OFBiz what resources (database and business logic access) are available for this web application and how to handle web-related issues, such as welcome pages, redirects, and error pages.
4. Create a file named "web.xml"(web.xml follows j2ee webapp specs). Contents of this file can be copied from any of the existing component e.g. /framework/example component. The Important values to change are the <display-name>, the localDispatcherName, the mainDecoratorLocation and the webSiteId.

   Code Block

   <context-param> <param-name>webSiteId</param-name> <param-value>PRACTICE</param-value> <description>A unique ID used to look up the WebSite entity to get information about catalogs, etc.</description> </context-param> <context-param>      <param-name>localDispatcherName</param-name>      <param-value>practice</param-value>      <description>A unique name used to identify/recognize the local dispatcher for the Service Engine</description> </context-param> <context-param>      <param-name>mainDecoratorLocation</param-name>      <param-value>component://practice/widget/CommonScreens.xml</param-value>      <description>The location of the main-decorator screen to use for this webapp; referred to as a context variable in screen def XML files.</description> </context-param>

   1. For now just put websiteId as "PRACTICE", you will explanation after some time in this tutorial only.
   2. For now put the value: "component://practice/widget/CommonScreens.xml" in for the mainDecoratorLocation and you will see why in a while. This location is used in pointing to the main decorator location in screens like

      Code Block
      ${parameters.mainDecoratorLocation}

      Which increases the code Independence from changing the path at many places when we need to change the main decorator location. At that time we just need to change the location there only and it will work for all the screens where it has been used. One more advantage of doing this in screens is the purpose of resuability of existing screens which we can use from other components, but it decorate that screen by your decorator only as the same pattern is used at all the places and in all the components to show the mainDecoratorLocation. Concentrate on this when you add decorators in your screens in not too distant future with the development of this application.
5. Create a file named "controller.xml" (used by ofbiz webapp controller)  This file will be small and simple at first but will grow as we add functionality later on. For now insert the following code:

   Code Block

   <?xml version="1.0" encoding="UTF-8"?> <site-conf xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="http://ofbiz.apache.org/dtds/site-conf.xsd"> <include location="component://common/webcommon/WEB-INF/common-controller.xml"/> <description>Practice Component Site Configuration File</description> <owner>Copyright 2001-2009 The Apache Software Foundation</owner> <handler name="screen" type="view" class="org.ofbiz.widget.screen.ScreenWidgetViewHandler"/> <!-- Request Mappings --> <request-map uri="main"> <security https="false" auth="false"/> <response name="success" type="view" value="main"/> </request-map> <!-- end of request mappings --> <!-- View Mappings --> <view-map name="main" type="screen" page="component://practice/widget/PracticeScreens.xml#main"/> <!-- end of view mappings --> </site-conf>

6. Move up one level and create a new directory named 'error'(hot-deploy/practice/webapp/practice/error).
   1. Create a file error.jsp inside the "error" directory. Contents of this file can be copied from any of the existing component e.g. example component.
      The location of your error page will be specified in the beginning of your controller.xml file like <errorpage>/error/error.jsp</errorpage> . You will need to make or copy over a /webapp/practice/error/error.jsp page to show an error message to the user.
7. Create a sub-directory inside your component directory "practice" named "widget"(hot-deploy/practice/widget). This directory will contain your forms, menus, and screens which will be created for UI.
8. Create a file inside the directory "widget" named "PracticeScreens.xml". Contents of this file can be copied from any existing component  e.g. example component.
   As now onwards you will be able to create screens views so an important reading at this place will be Best Practices Guide.

   Code Block
   <?xml version="1.0" encoding="UTF-8"?> <screens xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="http://ofbiz.apache.org/dtds/widget-screen.xsd"> <screen name="main"> <section> <widgets> <label text="This is first practice"/> </widgets> </section> </screen> </screens>

9. Now that we have the basic elements in place let's review the basic flow no matter how large or complex your component gets. First, a request will be made by a browser to see a specific resource. Take for example the request: "localhost:8080/practice/control/main"
   1. When OFBiz sees this request it will look at the /practice section first. This is because in our ofbiz-component.xml file we said our webapps mount point would be /practice. Now OFBiz knows that our practice component will handle the rest of the request.
   2. OFBiz will then look at our controller.xml file. Inside our controller.xml file we have request-maps and view-maps. If it finds a request-map with the name 'main' it will use the associated view-map, as follows. The request-map can either specify a view, or as we will see later an event or a service. If it specifies a view it will look further down in the controller.xml file and see if there is a view-map with the name specified by the value tag in the request-map.
   3. For now we will keep it simple and assume that all the views go to a type=screen. If this is the case then the page tag will specify a path to a screen definition file as well as a screen name to display after the "#" sign.
10. Now its the time to run you first practice application!
    Start the server by typing the following at the command line : java -Xmx256M -jar ofbiz.jar (the -Xmx256M command just ensures that the program has enough memory) Then, hit the url http://localhost:8080/practice/control/main in your browser.  Your browser should show "This is first practice" as seen below.
    Output Screen :
    
11. Create a file in the webapp directory "practice" named index.jsp (Contents of this file can be copied from the "example" component). This file is responsible for redirecting the response to control/main if you give a url such as  http://localhost:8080/practice/. If you give a url such as http://localhost:8080/practice/unknown/requestit will be redirected to the redirectPath specified in web.xml. In that case, ContextFilter will filter out the request and use the redirect path to redirect the request.

...

1. Take reference from ExampleMenus.xml file for having login and logout options in your menu.
   Targets for these options will be available from "component://common/webcommon/WEB-INF/common-controller.xml", which we have to include in our controller.xml.
   or you can do these entries in your controller.xml file under

   Code Block

   <!- Request Mappings -> <!-- Security Mappings --> <request-map uri="checkLogin" edit="false"> <description>Verify a user is logged in.</description> <security https="true" auth="false"/> <event type="java" path="org.ofbiz.webapp.control.LoginWorker" invoke="checkLogin" /> <response name="success" type="view" value="main"/> <response name="error" type="view" value="login"/> </request-map> <request-map uri="login"> <security https="true" auth="false"/> <event type="java" path="org.ofbiz.webapp.control.LoginWorker" invoke="login"/> <response name="success" type="view" value="main"/> <response name="error" type="view" value="login"/> </request-map> <request-map uri="logout"> <security https="true" auth="true"/> <event type="java" path="org.ofbiz.webapp.control.LoginWorker" invoke="logout"/> <response name="success" type="request" value="checkLogin"/> <response name="error" type="view" value="main"/> </request-map>

   These requests are needed to add in your controller only when you have not included any of the other component controller which consist of these requests. So if you have already included common-controller.xml file then you don't need to explicitly do these entries in your controller.    
   and the same view we have in place can be used for which we have entry in common-controller.xml file we can also have our own:

   Code Block
   <view-map name="login" type="screen" page="component://common/widget/CommonScreens.xml#login"/>

2. Make changes in requests in controller.xml file make auth="true" means now these requests needs authentication.
   This is first security level which you have implemented. you request should look like :

   Code Block
   <request-map uri="main"> <security https="true" auth="true"/> <response name="success" type="view" value="main"/> <response name="error" type="view" value="main"/> </request-map>

   Now run your application and observe the difference. you can login by user name : admin and pwd: ofbizHere we should understand why we had given the permission "OFBTOOLS" in base-permission in ofbiz-component.xml file. To understand this please read following carefully and perform steps as mentioned:
   Confirm that user 'admin' has the 'OFBTOOLS' permission.
   1. Login into partymanager to confirm that the user admin has the required permission https://127.0.0.1:8443/partymgr/control/main
   2. Once your logged in search for the user by typing 'admin' in the User Login field and then clicking the Lookup Party button.
   3.    This does a wild char*  search and you should see multiple users returned.Click the 'Details' button for the admin user.
      Note : Important point to note here is that the person 'Mr. THE PRIVILEGED ADMINISTRATOR' has a partyId admin has multiple login Ids as listed in the
      User Name(s) form.
   4. We interested in the admin user login so click on the 'Security Groups' button and confirm that the use 'admin' is part of the 'FULLADMIN' group. The Groups that the user belongs to is shown in the bottom list form Drill down on the FULLADMIN.
   5. Click on the Permissions tab. This tab shows all the permissions for the FULLADMIN security group. Navigate between the permissions till you find the OFBTOOLS permissions.
      'OFBTOOLS_VIEW Permission to access the Stock OFBiz Manager Applications.' This confirms that the userlogin 'admin' has the permission 'OFBTOOLS'
   6. Take a moment  to review the entity model as it relates to users and permissions. The arrow represents the many side of the relationship.An really important reading at this moment is at : OFBiz Security

Part 3

Writing CrUD Operations

...

ECA : It is a combinition of 3 things: an event, conditions per event, and actions per event. It is a rule used to trigger an action upon the execution of an event when certain conditions are met. When a service is called for example a lookup is performed to see if any ECAs are defined for this event. Events include before authentication, before IN parameter validation, before actual service invocation, before OUT parameter validation, before transaction commit, or before the service returns. Next, each condition in the ECA definition is evaluated and if all come back as true, each action is performed. An action is just a service which must be defined to work with the parameters already in the service's context. There is no limit to the number of conditions or actions each ECA may define.
For more details on this visit :  Service Engine Guide

1. SECA (Service Event Condition Action) : This is used when we want to trigger another service(action) on the execution of a service when certain conditions are met.
2. EECA (Entity Event Condition Action) : This is used when we want to trigger a service on the creation of a record for an entity when certain conditions are met.
   For the implementation of ECA again we will be following the same approach for screens, menus by following steps:

...

    Group services are used to call more then one services as a group. Service groups are a set of services which should run when calling the initial service. You define a service using the group service engine, and include all the parameters/attributes needed for all the services in the group. The location attribute is not needed for groupservices, the invoke attribute defines the name of the group to run. When this service is invoked the group is called and the services defined in the group are called as defined.
For mor details on this visit :http://docsofbiz.ofbizapache.org/display/OFBTECH/Service+Engine+Guidedocs/services.html
For the implementation of Group service follow these steps:

...

The interface service engine has been implemented to help with defining services which share a number of the same parameters. An interface service cannot be invoked, but rather is a defined service which other services inherit from. Each interface service will be defined using the interface engine.
For more details on this visit :  http://docsofbiz.ofbizapache.org/display/OFBTECH/Service+Engine+Guidedocs/services.html
For implemeting the interface follow these steps:

...

1. Create a new subdirectory by name entitydef in hot-deploy/practice/.
2. Create new file by name  entitymodel.xml. This file will contain the defintions of entities which you want to define.
3. For loading the defintion you need to do an entry in your ofbiz-component.xml file like:

   Code Block
   <entity-resource type="model" reader-name="main" loader="main" location="entitydef/entitymodel.xml"/>

   That implies that when ever you do a change you need to restart the server to have those changes in effect.
   At this place an important reading is at http://docsofbiz.ofbizapache.org/display/OFBTECH/General+Entity+Overviewdocs/entity.html.
   You will rarely find this way to define new entity because you are already having entities there in OFBiz already defined which will be useful for the conduction of your business process. Though you may feel at some place to add more fields to an existing entity so how can you do that? The next  step will show you the way how you can extend an entity for your customized needs.
   Earlier we used to have one more file in same directory by name entitygroup.xml which not needed any more because code is checked in to the trunk for this.

...

If you have followed all the steps and developed practice application from this tutorial then this will really help you in understanding other implementation in OFBiz. These things are basic foundation of working in OFBiz. Now you know, how you can start the development in OFBiz. Don't leave the extra links provided in this tutorial as they will really help you a lot in understanding the things which are there in detail.
Here is another good reading will be help you a lot is available at FAQ Tips Tricks Cookbook HowTo
Now the next thing comes in the way is the business processes which are really needed to be read out for understanding OOTB process flow in OFBiz and OOTB data model, so for this, books are available at : OFBiz Related Books.

Now you are ready to dive in. Welcome to OFBiz world.

...