How-To Tutorials

(For more resources on Blender, see here.) Interface One of the most important parts of any software is the interface, and with Blender, it is no different. But the Blender interface is unique, because it's all based on OpenGL graphics built in real-time that can be redesigned any way we want. Because of that, we can say that Blender has a default interface that can be customized any way we want. It's even possible to zoom all the items in menus and buttons. Let's take a look at the interface: (move cursor over image to enlarge) The default interface of Blender is divided into: 3D View: This is the section of the interface where you visualize all your objects and manipulate them. If you are in the modeling process, this window should always be visible. Buttons Window: Here we will find almost all the tools and menus, with options to set up features like modifiers, materials, textures, and lights. We can change the options available in this window with several small icons that change the buttons with specific tasks like materials, shading, editing, and others. Those buttons will reflect the active panel in Blender, for example, when we choose materials (F5 key). The Buttons window will then only show options related to materials. Header: All windows in Blender have a header, even if it's not visible at the time we create the window. The content of the header can change, depending on the window type. For example, in the header for the 3D View, we find options related to visualization, object manipulation, and selection. Menus: These menus work just like in any other application, with options to save files, import, and export models. Depending on the window type selected, the contents of the menu may differ. Scene Selector: We can create various scenes in Blender, and this selector allows us to choose and create these scenes. Because we will be modeling and dealing with scenery, the Scene selector will be an important tool for us. These parts make up the default interface of Blender, but we can change all aspects of the interface. There are even some modified screens, adapted to some common tasks with Blender, for us to choose. To access these modified screen sets, we must click on the selector located to the left of Scene Selector: There are screen sets prepared to work with Animation, Model, Material, Sequence, and Scripting. Each of these sets has a different interface organization, optimized for its specific task. A nice way to switch between these sets is with a keyboard shortcut, which is Ctrl plus left arrow or right arrow. Try this shortcut, and you will switch between sets very quickly. If you make any changes in the interface of Blender and want to overwrite the default interface, just press Ctrl + U, and your current interface will become the new default. In this way, every time Blender is started, your new interface will be shown. The same option can be reached in the File menu with the option named Save Default Settings. To restore the standard default interface, just use the option Load Factory Settings in the File menu. Windows and menus Blender has a lot of different windows that can do a lot of nice things. Two of the most common windows are the 3D View and the Buttons Window, but there are a lot more. With the Window type selector, we can choose among several types, such as File Browser, Text Editor, Timeline, and others. The Window type selector is always located in the left corner of each window, as shown in the following screenshot: Let's see what the function of each window is: Scripts Window: This window groups some nice scripts written in Python to add some extra tools and functionalities to Blender. It works much like plugins in other 3D Packages. There are scripts to help in a lot of different tasks like modeling, animation, and importing models. Some of these scripts are very helpful to architectural modeling such as Geom Tool and Bridge Faces. For instance, we can create a city space with only a few mouse clicks using a script named Discombobulator. In most cases, the scripts will appear in the right place in the Blender menus. Use this window only if you want to browse all scripts available in your Blender Scripts folder. To run a script, just select any script from the Scripts menu. File Browser: With this window, we can browse the files of a specific folder. This window appears automatically when we save or open a file. Image Browser: Here we can view the image files in a specific folder. This window is very useful to search for image files like .jpg, .png, and others. Node Editor and Compositing Nodes: With this window, it's possible to build node sets and create complex materials and textures. Buttons Window: We already have talked about this window, but it's nice to remember that after the 3D View, this is one of the most important windows, because here we can set options for almost any tool or functionality in Blender. This is the window responsible for several tools and functions in Blender, such as lights, materials, textures, and object properties. Outliner: This window shows us a list of the objects in your scene, and lists the relations among them. Here we can see if an object is related to some other object in a hierarchical way. In this window, we can easily hide and select objects, which may be useful for complex scenes. User Preferences: As the name suggests, here we can change Blender configurations, such as file paths, themes, Auto Save, and other options. Text Editor: This window allows us to write and open text files to make comments and place notes. We can open and run Python scripts here also. Audio Window: Here we can open and compose audio files in sequences. It works much like the Video Sequence Editor, but for audio files. Timeline: That's the place where we create animation. This window gives us nice tools to add key frames and build animations. Video Sequence Editor: Here we can build and composite images and video files. It's a very nice window that can replace a video editor in some ways. We can easily create a complex animation with a lot of shots and sequence them together with this window. And, we can use the Node Editor to create complex compositions and effects. UV/Image Editor: With this window, we can edit and set up images and textures. There is even a paint application, with which we can edit and make adjustments in textures and maps. This is a very important window for us, because a lot of the texture work we will be using will involve the use of UV Textures that require a lot of adjustments in the UV/Image Editor. NLA Editor: Here we can visualize and set up non-linear animations. This window is related more to animations and key frame visualization. A non-linear animation means that we can create small blocks of motions, which can be arranged any way we like, including copying and positioning those blocks into sequences. In Blender, these blocks are named strips. Because it's a non-linear editor, we can erase and rearrange the blocks without a break in the animation. For a linear animation system, any changes at the beginning of the animation would demand a full reconstruction of the animation from the artist. Action Editor: This window has nice options to set up actions related to character animation. Ipo Curve Editor: In this window, we can create and set up animations in a more visual way with curves. It's possible to add, edit, and delete key frames. Even for animations that don't require much work with characters and object deformations, like the ones we will be creating, it still requires a lot of work in the setup of curves to create good animation. Now we know what each of those windows do. Some of them will be very important for your visualization tasks, such as the Buttons and Scripts Window. Multiple windows A great feature in Blender is the ability to split the interface and use various window types at the same moment. The way to do this is very simple. We must right-click on the borders of an existing window to access a small menu with the options to split the window. We can split a window in two ways, which are vertical division and horizontal division. When you place the mouse cursor at the border of a window, the cursor will change into a double arrow. Just right-click and choose Split Area from the menu as shown in the next screenshot, and a division will be created: There are two kinds of divisions that we can create, which are vertical and horizontal divisions: Vertical: Click on the upper or lower border of a window to create a vertical division Horizontal: Click on the right or left border of a window to create a horizontal division After choosing Split Area, just place your mouse cursor where you wish the division to be created, and left-click with your mouse. Merge windows It's possible to merge two different windows too, with the same menu. There is an option named Join Areas, which will appear when we click with our right mouse button on the border of a window. After doing that, a big arrow will show which window will be destroyed and the arrow base shows the window that will take the place of the one destroyed: When you have chosen which windows should be joined, just left-click with your mouse to confirm it. We must always join windows that share the entire border with each other. Windows that only share a part of their borders can't be joined together, and we must find another way to join those windows.

What is Unit testing and what it is not? The title of this section, begs another question: "Why do I care?" One answer is that Unit testing is a best practice that has been evolving toward its current form over most of the time that programming has existed. Another answer is that the core principles of Unit testing are just good sense; it might actually be a little embarrassing to our community as a whole that it took us so long to recognize them. Alright, so what is Unit testing? In its most fundamental form, Unit testing can be defined as testing the smallest meaningful pieces of code (such pieces are called units), in such a way that each piece's success or failure depends only on itself. For the most part, we've been following this principle already. There's a reason for each part of this definition: we test the smallest meaningful pieces of code because, when a test fails, we want that failure to tell where the problem is us as specifically as possible. We make each test independent because we don't want a test to make any other test succeed, when it should have failed; or fail when it should have succeeded. When tests aren't independent, you can't trust them to tell you what you need to know. Traditionally, automated testing is associated with Unit testing. Automated testing makes it fast and easy to run unit tests, which tend to be amenable to automation. We'll certainly make heavy use of automated testing with doctest and later with tools such as unittest and Nose as well. Any test that involves more than one unit is automatically not a unit test. That matters because the results of such tests tend to be confusing. The effects of the different units get tangled together, with the end result that not only do you not know where the problem is (is the mistake in this piece of code, or is it just responding correctly to bad input from some other piece of code?), you're also often unsure exactly what the problem is this output is wrong, but how does each unit contribute to the error? Empirical scientists must perform experiments that check only one hypothesis at a time, whether the subject at hand is chemistry, physics, or the behavior of a body of program code. Time for action – identifying units Imagine that you're responsible for testing the following code: class testable: def method1(self, number): number += 4 number **= 0.5 number *= 7 return number def method2(self, number): return ((number * 2) ** 1.27) * 0.3 def method3(self, number): return self.method1(number) + self.method2(number) def method4(self): return 1.713 * self.method3(id(self)) In this example, what are the units? Is the whole class a single unit, or is each method a separate unit. How about each statement, or each expression? Keep in mind that the definition of a unit is somewhat subjective (although never bigger than a single class), and make your own decision. Think about what you chose. What would the consequences have been if you chose otherwise? For example, if you chose to think of each method as a unit, what would be different if you chose to treat the whole class as a unit? Consider method4. Its result depends on all of the other methods working correctly. On top of that, it depends on something that changes from one test run to another, the unique ID of the self object. Is it even possible to treat method4 as a unit in a self-contained test? If we could change anything except method4, what would we have to change to enable method4 to run in a self-contained test and produce a predictable result? What just happened? By answering those three questions, you thought about some of the deeper aspects of unit testing. The question of what constitutes a unit, is fundamental to how you organize your tests. The capabilities of the language affects this choice. C++ and Java make it difficult or impossible to treat methods as units, for example, so in those languages each class is usually treated as a single unit. C, on the other hand, doesn't support classes as language features at all, so the obvious choice of unit is the function. Python is flexible enough that either classes or methods could be considered units, and of course it has stand-alone functions as well, which are also natural to think of as units. Python can't easily handle individual statements within a function or method as units, because they don't exist as separate objects when the test runs. They're all lumped together into a single code object that's part of the function. The consequences of your choice of unit are far-reaching. The smaller the units are, the more useful the tests tend to be, because they narrow down the location and nature of bugs more quickly. For example, one of the consequences of choosing to treat the testable class as a single unit is that tests of the class will fail if there is a mistake in any of the methods. That tells you that there's a mistake in testable, but not (for example) that it's in method2. On the other hand, there is a certain amount of rigmarole involved in treating method4 and its like as units. Even so, I recommend using methods and functions as units most of the time, because it pays off in the long run. In answering the third question, you probably discovered that the functions id and self.method3 would need to have different definitions, definitions that produced a predictable result, and did so without invoking code in any of the other units. In Python, replacing the real function with such stand-ins is fairly easy to do in an ad hoc manner. Unit testing throughout the development process We'll walk through the development of a single class, treating it with all the dignity of a real project. We'll be strictly careful to integrate unit testing into every phase of the project. This may seem silly at times, but just play along. There's a lot to learn from the experience. The example we'll be working with is a PID controller. The basic idea is that a PID controller is a feedback loop for controlling some piece of real-world hardware. It takes input from a sensor that can measure some property of the hardware, and generates a control signal that adjusts that property toward some desired state. The position of a robot arm in a factory might be controlled by a PID controller. If you want to know more about PID controllers, the Internet is rife with information. The Wikipedia entry is a good place to start: http://en.wikipedia.org/wiki/PID_controller. Design phase Our notional client comes to us with the following (rather sparse) specification: We want a class that implements a PID controller for a single variable. The measurement, setpoint, and output should all be real numbers. We need to be able to adjust the setpoint at runtime, but we want it to have a memory, so that we can easily return to the previous setpoint. Time for action - unit testing during design Time to make that specification a bit more formal—and complete—by writing unit tests that describe the desired behavior. We need to write a test that describes the PID constructor. After checking our references, we determine that a PID controller is defined by three gains, and a setpoint. The controller has three components: proportional, integral and derivative (hence the name PID). Each gain is a number that determines how much one of the three parts of the controller has on the final result. The setpoint determines what the goal of the controller is; in other words, to where it's trying to move the controlled variable. Looking at all that, we decide that the constructor should just store the gains and the setpoint, along with initializing some internal state that we know we'll need due to reading up on the workings of a PID controller: >>> import pid>>> controller = pid.PID(P=0.5, I=0.5, D=0.5, setpoint=0)>>> controller.gains(0.5, 0.5, 0.5)>>> controller.setpoint[0.0]>>> controller.previous_time is NoneTrue>>> controller.previous_error0.0>>> controller.integrated_error0.0 We need to write tests that describe measurement processing. This is the controller in action, taking a measured value as its input and producing a control signal that should smoothly move the measured variable to the setpoint. For this to work correctly, we need to be able to control what the controller sees as the current time. After that, we plug our test input values into the math that defines a PID controller, along with the gains, to figure out what the correct outputs would be: >>> import time>>> real_time = time.time>>> time.time = (float(x) for x in xrange(1, 1000)).next>>> pid = reload(pid)>>> controller = pid.PID(P=0.5, I=0.5, D=0.5, setpoint=0)>>> controller.measure(12)-6.0>>> controller.measure(6)-3.0>>> controller.measure(3)-4.5>>> controller.measure(-1.5)-0.75>>> controller.measure(-2.25)-1.125>>> time.time = real_time We need to write tests that describe setpoint handling. Our client asked for a setpoint stack, so we write tests that check such stack behavior. Writing code that uses this stack behavior brings to our attention that fact that a PID controller with no setpoint is not a meaningful entity, so we add a test that checks that the PID class rejects that situation by raising an exception. >>> pid = reload(pid)>>> controller = pid.PID(P = 0.5, I = 0.5, D = 0.5, setpoint = 0)>>> controller.push_setpoint(7)>>> controller.setpoint[0.0, 7.0]>>> controller.push_setpoint(8.5)>>> controller.setpoint[0.0, 7.0, 8.5]>>> controller.pop_setpoint()8.5>>> controller.setpoint[0.0, 7.0]>>> controller.pop_setpoint()7.0>>> controller.setpoint[0.0]>>> controller.pop_setpoint()Traceback (most recent call last):ValueError: PID controller must have a setpoint What just happened? Our clients gave us a pretty good initial specification, but it left a lot of details to assumption. By writing these tests, we've codified exactly what our goal is. Writing the tests forced us to make our assumptions explicit. Additionally, we've gotten a chance to use the object, which gives us an understanding of it that would otherwise be hard to get at this stage. Normally we'd place the doctests in the same file as the specification, and in fact that's what you'll find in the book's code archive. In the book format, we used the specification text as the description for each step of the example. You could ask how many tests we should write for each piece of the specification. After all, each test is for certain specific input values, so when code passes it, all it proves is that the code produces the right results for that specific input. The code could conceivably do something entirely wrong, and still pass the test. The fact is that it's usually a safe assumption that the code you'll be testing was supposed to do the right thing, and so a single test for each specified property fairly well distinguishes between working and non-working code. Add to that tests for any boundaries specified—for "The X input may be between the values 1 and 7, inclusive" you might add tests for X values of 0.9 and 7.1 to make sure they weren't accepted—and you're doing fine. There were a couple of tricks we pulled to make the tests repeatable and independent. In every test after the first, we called the reload function on the pid module, to reload it from the disk. That has the effect of resetting anything that might have changed in the module, and causes it to re-import any modules that it depends on. That latter effect is particularly important, since in the tests of measure, we replaced time.time with a dummy function. We want to be sure that the pid module uses the dummy time function, so we reload the pid module. If the real time function is used instead of the dummy, the test won't be useful, because there will be only one time in all of history at which it would succeed. Tests need to be repeatable. The dummy time function is created by making an iterator that counts through the integers from 1 to 999 (as floating point values), and binding time.time to that iterator's next method. Once we were done with the time-dependent tests, we replaced the original time.time. Right now, we have tests for a module that doesn't exist. That's good! Writing the tests was easier than writing the module will be, and it gives us a stepping stone toward getting the module right, quickly and easily. As a general rule, you always want to have tests ready before the code that they test is written. Have a go hero Try this a few times on your own: Describe some program or module that you'd enjoy having access to in real life, using normal language. Then go back through it and try writing tests, describing the program or module. Keep an eye out for places where writing the test makes you aware of ambiguities in your prior description, or makes you realize that there's a better way to do something.

(For more resources on BPEL, SOA and Oracle see here.) To log into Oracle Service Bus Console, we have to open a web browser and access the following URL: http://host_name:port/sbconsole, where host_name is the name of the host on which OSB is installed and port is a number that is set during the installation process. We log in as user weblogic. The Oracle Service Bus Console opens, as shown in the following screenshot: The Dashboard page is opened by default, displaying information about alerts. We will show how to defne and monitor alerts later in this article. In the upper-left corner, we can see the Change Center. Change Center is key to making confguration changes in OSB. Before making any changes, we have to create a new session by clicking the Create button. Then, we are able to make different changes without disrupting existing services. When fnished, we activate all changes by clicking Activate. If we want to roll back the changes, we can click the Discard button. We can also view all changes before activating them and write a comment. Creating a project and importing resources from OSR First, we have to create a new session, by clicking the Create button in the Change Center. Next, we will create a new project. OSB uses projects to allow logical grouping of resources and to better organize related parts of large development projects. We click on the Project Explorer link in the main menu. In the Projects page, we enter the name of the project (TravelApproval) and click Add Project. The new project is now shown in the projects list on the left side in the Project Explorer. We click on the project. Next, we add folders to the project, as we want to group resources by type. To create a folder, we enter the folder name in the Enter New Folder Name field and click Add folder. We add six folders: BusinessServices, ProxyServices, WSDL, XSD, XSLT, and AlertDestinations. Next, we have to create resources. We will show how to import service and all related resources from the UDDI registry. Before creating a connection to the UDDI registry, we will activate the current session. First, we review all changes. We click the View Changes link in the Change Center. We can see the list of all changes in the current session. We can also undo changes by clicking the undo link in the last column. Now, we activate the session by clicking on the Activate button. The Activate Session page opens. We can add a description to the session and click Submit. Now, all changes made are activated. Creating connection to Oracle Service Registry First, we start a new session in the Change Center. Then we click on the System Administration link in the main menu. We click on the UDDI Registries and then Add registry on the right side of the page. We enter connection parameters and click Save. Now, the registry is listed in the UDDI Registries list, as shown next: We can optionally activate a current session. In that case, we have to create a new session before importing resources from UDDI. Importing resources from Oracle Service Registry We click on the Import from UDDI link on the left-hand side. As there is only one connection to the registry, this connection is selected by default. First, we have to select the Business Entity. We select Packt Publishing. Then we click on the Search button to display all services of the selected business entity. In the next screenshot, we can see that currently there is only one service published. We select the service and click Next. In the second step, we select the project and folder, where we want to save the resources. We select the TravelApproval project and the folder BusinessServices and click Next. On the fnal screen, we just click the Import button. Now we can see that a business service, a WSDL, and three XSD resources have been created. All resources have been created automatically, as we imported a service from the UDDI registry. If we create resources by hand, we frst have to create an XML Schema in WSDL resources, and then the Business service. As all resources have been saved to the BusinessServices folder, we have to move them to appropriate folders based on their type. We go back to the Project Explorer and click on the BusinessServices folder in the TravelApproval project. We can see all imported resources in the Resources list at the bottom of the page. We can move resources by clicking on the Move Resource icon and then selecting the target folder. We move the WSDL resource to the WSDL folder and the XML Schemas to the XSD folder. Configuring a business service If we want to monitor service metrics, such as average response time, number of messages, and number of errors, we have to enable monitoring of the business service. We will also show how to improve performances by enabling service result caching, which is a new feature in OSB 11g PS2. Enabling service result caching OSB supports service result caching through the use of Oracle Coherence, which is an in-memory data grid solution. In this way, we can dramatically improve performances if the response of the business service is relatively static. To enable the use of service result caching globally, we have to open the Operations | Global Settings and set Enable Result Caching to true.. In the Project Explorer, we click on our Business service. On the Confguration Details tab, we will enable service result caching. We scroll-down and edit the Message Handling Confguration. Then we expand the Advanced Settings. We select the Result Caching checkbox. Next, we have to specify the cache token, which uniquely identifes a single cache result. This is usually an ID field. In our simplifed example, we do not have an ID field; therefore, we will use the employee last name for testing purposes. We enter the following cache token expression: $body/emp:employee/LastName. Then we set the expiration time to 20 minutes. Then, we click Next and Save. Now, if the business service locates cached results through a cache key, it returns those cached results to the client instead of invoking the external service. If the result is not cached, the business service invokes the external service, returns the result to the client, and stores the result in cache. Service result caching works only when the business service is invoked from a proxy service. Enabling service monitoring Again, we click on our Business service and then click on the Operational Settings tab. We select the Enabled checkbox next to the Monitoring and set the Aggregation Interval to 20 minutes. The aggregation interval is the sliding window of time over which metrics are computed. We can also defne SLA alerts which are based on these metrics. We click Update to save the changes. Then, we activate the changes by clicking on the Activate button in the Change Center. Testing a business service After activating the changes, we can test the business service using the Test Console. To open the console, we select the BusinessServices folder and then click on the bug icon next to the Business service. The Test Console opens. We set the XML payload and click the Execute button. After executing the Business service, we can see the response message as shown in the next screenshot: Creating an Alert destination Before creating a proxy service, we will create an Alert Destination resource, which will be later used for sending e-mail alerts to the administrator. Remember, that we have already created the AlertDestinations folder. To be able to send e-mail alerts, we have to frst confgure the SMTP server on the System Administration page. To create an Alert destination, we navigate to the AlertDestinations folder and then select the Alert Destination from the Create Resource drop-down. We set the name to Administrator and add an e-mail recipient by clicking the Add button. We enter the recipient e-mail address (we can add more recipients) and select the SMTP server.   Then we click Save twice. Creating a proxy service Although at the frst sight it might seem redundant, using a proxy service instead of calling the original business service directly has several advantages. If we add a proxy service between the service consumer and the original service, we gain transparency. Through OSB, we can monitor and supervise the service and control the inbound and outbound messages. This becomes important when changes happen. For example, when a service interface or the payload changes, the proxy service can mask the changes to all service consumers that have not yet been upgraded to use the new version. This is, however, not the only beneft. A proxy service can enable authentication and authorization when accessing a service. It can provide a means to monitor service SLAs, and much more. Therefore, it often makes sense to consider using proxy services. We will show an example to demonstrate the capabilities of proxy services. We will create a proxy service, which will contain the message processing logic and will be used to decouple service clients from the service provider. Our proxy service will validate the request against the corresponding XML schema. It will also perform error handling and alert the service administrator of any problems with the service execution. First, we start a new session (if there is no active session) by clicking the Create button in the Change Center. Then we navigate to the ProxyServices folder in the Project Explorer. We click on the Create Resources drop-down and select Proxy Service. The General Confguration page opens. We set the name of the proxy service to EmployeeTravelStatusServiceProxy. We also have to defne the interface of the service. We select the Business service, as we want the proxy service to use the same interface as the business service. We click the Browse button and select the EmployeeTravelStatusService business service. Then we click Next. On the Transport Configuration screen, we can change the transport Protocol and Endpoint URI. We use the defaults values and click Next. The HTTP Transport Confguration screen opens. We click Next on the remaining confguration screens. On the Summary page, we click the Save button at the bottom of the page.

(For more resources on SugarCRM, see here.) Before you investigate that section of this article, it is important to review some of the issues that should be accounted for when deploying your own server. Some of the important items from that list include the following: Selecting an operating system: You must weigh the value of using Windows Server versus Linux (or other operating system) and vice-versa. Hardware configuration of the server: It must be capable of handling your expected immediate load, plus allow for at least 18 to 24 months of expected growth. Identify existing infrastructure that may be repurposed for the task: Your deployment does not require new hardware; it requires hardware capable of handling the current load with some room for growth. Establish a powerful data backup and security plan: The data in your CRM system is arguably the most valuable information your business owns. You must treat it as such, and plan for the worst. You must be able to quickly recover from anything, including theft of hardware and a natural disaster. Internet bandwidth: The current Internet connection at your office may be sufficient for today's e-mail and web browsing needs, but may not be adequate for responsive use of your CRM system, especially if you are using an On-Demand provider. As mentioned previously, this article does not specifically cover the process of installing your CRM system; however, it does discuss the aforementioned issues in detail. This information should help you make well-informed decisions for your deployment. Deployment alternatives One of the advantages of using SugarCRM as your CRM solution is its flexibility in a number of areas. For now, the flexibility we are most concerned with is its ability to be installed in a variety of environments. SugarCRM is rather unique in its breadth of supported deployment options. The four basic options from which you must choose are as follows: On-Demand: In this situation, you pay a fee for the right to use the SugarCRM application. Fees are usually based on a per month and per user model, but can vary greatly depending on the provider. The advantage of this deployment is the quick time to deployment and elimination of responsibilities, such as backing up the server and so forth. Some of the reasons why businesses choose not to use this model include the following: The data resides on someone else's server There is a limited access to the data beyond the application There are limits on some of the customizations that can be applied to the system The latter point can become a real issue if you intend to integrate your CRM system extensively. Collocation: The main difference between this option and the previous one is that you are supplying the server that will host your installation, as opposed to paying a fee for the right to use a preconfigured one. As you are responsible for providing the server, you are also responsible for making the appropriate hardware purchases that will provide redundancy and high availability. You must still pay a monthly fee while also assuming the responsibility of configuring and maintaining the hardware, although many collocation providers offer maintenance services at an additional cost that may fit your budget. In addition, you are also responsible for installing and maintaining your SugarCRM installation; although, this level of control over your server and installation also eliminates the various limitations inherited by On-Demand environments. Collocation is also helpful for addressing bandwidth and disaster recovery needs. Collocation service providers are able to provide high bandwidth connections that are likely to be cost-prohibitive if you were to try to get the same at your office. Their facilities are also equipped with solid security and backup measures. These measures protect your server and its data, part of which includes their inclusion of systems that handle emergencies, such as fire and power outages. On-Premise: This option should be fairly self-explanatory—you buy a server (or use the one you already have), then install the required software on it. In this model, you are taking on the responsibility for maintaining the hardware, installing the appropriate software and furthermore, addressing the security measures, such as backups, security, fire prevention, and others. However, the result is a system over which you have a complete control. Since this type of endeavor is sometimes beyond the financial means of many small businesses, there is a temptation to cut costs by eliminating some of the components, especially lesser valued items, such as security. Remember, the data in your CRM system is the lifeblood of your business. It is arguably the single most important asset of your business. Treat it as such. Shared Server: This is the least expensive, not surprisingly, and also the lowest capacity option. You have your SugarCRM instance hosted on a server whose capabilities you rent on a monthly basis and are shared with other users. Those services include not only server space, but also backup and other security services that were discussed previously. Due to the proliferation of hosting providers, costs for shared hosting services are within the reach of nearly all businesses. However, a vast majority of these service providers are in the business of providing generic hosting platforms that customers tend to use for hosting websites, as opposed to applications, such as SugarCRM. While many are able to provide services that are conducive to a positive experience with SugarCRM, it is not uncommon to run into providers whose services hinder its installation, performance, or overall usage. It is also not unheard of for a hosting provider to make system changes that in turn cause SugarCRM to no longer function. Again, their priority is not that you have a working SugarCRM system, but that their services are able to compete effectively in their market. This also means that the features they offer, such as direct access to the data, will vary by provider. For many businesses, the low cost is reason enough to overlook the potential risks and limitations, but nevertheless, you must be careful in your selection of a service provider if you are choosing this option. A deployment option that continues to rapidly grow in popularity is the use of cloud computing services, such as Amazon Elastic Compute Cloud (Amazon EC2) (http://aws.amazon.com/ec2/). It offers many of the same benefits as the collocation option; however, unlike collocation, you do not need to provide a physical server. You are renting a virtual server at costs as low as approximately US$100 per month (at the time of this writing), allowing you to deploy a very comprehensive solution. In addition to reduced costs, cloud computing also gives you the flexibility to effortlessly scale by adding additional servers by means of a few mouse clicks. This process allows you to double (triple, quadruple, and so on) your processing capacity in minutes—a process that in past years may have taken days to complete. The popularity of such services is such that you can even find a virtual server with SugarCRM already installed on it, eliminating the potentially complex setup work and bringing it closer to the turnkey model of the On-Demand option.   Let us look at a comparison chart of the various options which are as follows:   On-Demand On-Demand On-Premise Shared Server Initial cost Low Medium Medium Low Ongoing cost Medium/High Medium Low Low Initial setup Easy Complex Complex Somewhat complex Your ongoing effort Low Medium Medium Medium/High Custom fit Limited Excellent Excellent Varies Data security Excellent Excellent Self supplied Excellent Performance Excellent Excellent Likely excellent Varies A couple of important points can be extrapolated from the previous chart. First, note that your initial expenses will be higher with either the Collocation or On-Premise option. This makes perfect sense, as both require that you provide a physical server which you may have to purchase—unless you already have a suitable server available. Even then, you may still need to buy a Server Operating System. On a related note, you may also incur additional costs to develop and implement a data backup and security solution. It would also be a wise investment to pay an experienced SugarCRM consultant a nominal fee to install your system. The latter point touches on an unproductive scenario in which too many get trapped. Most entrepreneurs tend to have a "hands-on" mentality, meaning they like to do things for themselves as much as possible. Sometimes, this is out of necessity or shortage of financial resources, while on other occasions different motivators explain the behavior. The danger, however, is that installing a piece of software is sometimes a task best left to someone with more experience. It is not uncommon for some people to spend 3 to 4 hours (or days) attempting to complete the installation, whereas an experienced SugarCRM consultant should be able to do the same in well under an hour. You should weigh the value of your time against the costs that would be incurred from using a consultant. Unless your time is worth less than US$10/hour, you are likely to find that hiring a consultant to perform the task is a far more cost-effective approach. A second point of importance that should be highlighted on the chart relates to post-deployment costs. An On-Demand deployment requires little upfront investment, but in the long run, it may prove to be quite expensive. Your subscription is based on a per user, per month fee that usually starts at around US$30/month. Thus, a five user implementation would represent US$150/month or US$1,800/year. Furthermore, some On-Demand service providers require a commitment of at least 12 months or longer. Such arrangements represent not only a financial commitment, but also one to the CRM solution, underscoring the importance of diligently evaluating whether or not the feature set it offers will meet your business needs. The financial part may be a trivial matter for businesses with a small user count, as it removes the burden of maintaining a server, and others. However, if your business has more than 10 users, you should consider an On-Premise deployment, not only for financial reasons, but also to meet a wide variety of customization needs that may not be feasible in an On-Demand environment. If you use SugarCRM as an On-Demand service, you will, in all likelihood not have a whole server dedicated to running SugarCRM for your business. Instead, your service provider will most likely be using a shared server facility—a controlled portion of the resources of a physical server—to support your business' CRM deployment. If you are planning to use your CRM to house a lot of shared documents for your business, you should check with your On-Demand service provider if any disk space limitations are applicable to your subscription—they are often surprisingly low. From reviewing the table, you should also notice that the Shared-Server approach is the least cost-prohibitive option for deploying a CRM system. It is cost-effective, but your customization capabilities and ability to handle larger loads of data and users will vary greatly depending upon the service provider. You may quickly run into disk space issues if your service provider offers a limited amount of disk space and you intend to use a lot of files, documents, so on in conjunction with your CRM data. Some service providers also place restrictions on the amount of bandwidth you are allowed to use. Larger data and user loads are likely to cause that limit to be reached rather quickly. Due to the wide range of hosting providers and options available today, it is important to evaluate the various features they offer with great scrutiny. Some of the important factors include: disk space limits, shell access, remote MySQL connections, and bandwidth restrictions. In general, even in the best of scenarios, this option should not be used for more than 10 users. For most businesses with more than 10 employees, the choice between the deployment options is a trade-off between cost versus complexity, and effort. There is also an issue of comfort. Although On-Demand providers take a number of precautions to ensure system availability and safeguard data and servers (such as the use of surveillance equipment, secure server areas, and so on), the thought of relying on another party for this safety is sometimes beyond the comfort level of some businesses. Regardless of which option you select for your business, it is beneficial to have at least a basic understanding of the related technology features. Some of these features include bandwidth or connection speeds, performance and scalability, and backup and security procedures. This information will make you a knowledgeable consumer and in turn, assist you in your decision making process. In the case of On-Premise and Collocated deployments, there are additional topics of importance that must be discussed and evaluated. Although we lightly touched on some of these topics earlier in this section, it is important that we examine them in more detail. The section that follows will lead us through this examination. Choosing a server operating system Server and network operating systems have been around for a long time. Many years ago, Novell Netware, Banyan Vines, and numerous variants of UNIX (most notably, Solaris from Sun Microsystems) were the major players in this marketplace, but today, the largest players in network/server operating systems for small to medium-sized businesses are Microsoft Windows and Linux. Choosing which is best for your needs can be a confusing and sometimes a daunting process. Microsoft Windows, for example, is offered in a variety of flavors, including Web Edition, Standard Edition, Datacenter Edition, and others. In addition to pricing, the various editions also vary in their ability to scale, that is, handle more demanding computing needs. For example, 64-bit versions of the Web and Standard Editions are limited to 32 GB of RAM and do not support clustering— a technology used to provide redundancy and increase scalability. Datacenter Edition, on the other hand, not only supports clustering, but is also capable of supporting up to 2 TB of RAM (1000 GB = 1 TB). As you can see, your decision will vary greatly depending on your anticipated needs. If you expect a large volume of data (over a million accounts or contacts), you will want to ensure that you use a version of Windows that supports at least 8 GB of RAM. Data needs ranging in the area of 100,000 or less (accounts or contacts) are likely to function well with 4 GB of RAM, but you should remember the earlier statement that the hardware that you pick today should be capable of handling today's load, plus that expected within the next 18 to 24 months. If you have never used Linux before, but are considering it for your CRM server, you should prepare yourself for a vastly different selection process. First and foremost, Linux is available in many different flavors (commonly referred to as distributions or "distros"). The various distributions differ mostly on the structure of the file system (that is, the location of configuration files and tools) and included software. Strong opinions on which distribution is best are equally plentiful. We will, however, discuss the leading distributions, namely, Red Hat, Fedora Core, CentOS, and Ubuntu. Much like Windows, different iterations of these distributions will support different hardware configurations. However, unlike Windows, the costs incurred in using a more scalable version versus a less capable version do not change because the operating system is free. Red Hat is the exception to this rule. Red Hat's Enterprise Linux Server is a subscription based product ranging in price from US$349 to US$2,499 per year, per server. The subscription includes software updates and support. In contrast, costs for Windows Server 2008 begin at approximately US$470 per server for the Web Edition and can be as high as US$3,000 per processor for the Datacenter Edition. You are also likely to incur additional costs for Client Access Licenses (CAL), a license that allows a computer on your network to legally connect to a server and normally costs approximately US$30 each. These costs are for licenses only and do not include support services. A business with very limited financial resources may conclude that both—Red Hat Enterprise Linux and Windows Server—are beyond their means. Even if you are not in that situation, it is comforting to know that Fedora Core and CentOS are both widely used zero-cost alternatives, and also happen to be derivatives of Red Hat. CentOS in particular is intended to be a clone of Red Hat Enterprise Linux and it has a large following. If you have not heard of it before and are concerned about its viability, the fact that SugarCRM (the company) utilizes 64-bit versions of CentOS for its On-Demand datacenter (at the time of this writing) should help ease your fears. The final distribution mentioned was Ubuntu. Ubuntu is quite different, in that it has a long history of focusing on growing the adoption of Linux on the desktop. It has gained popularity primarily due to its ease of use. Server installations of Ubuntu are definitely possible and many users today are successfully using it for their SugarCRM implementations. In general, choosing one distribution versus another usually becomes a matter of personal preference and comfort. The cost involved in purchasing a server operating system has just been explained and the choice is yours. Clearly, were you to base your decision solely on licensing costs, Linux would be a more cost-effective choice. In practice, either of the operating systems is more than capable of fulfilling your CRM needs and in addition, each requires a certain amount of investment to maintain, and these costs are not readily visible up front. As a result, your selection is usually a choice more directly influenced by licensing and ongoing support costs, more so than licensing costs alone. The level and type of technical resources you have access to will no doubt have some influence on your choice. You will need someone to be on call in case of emergencies, perhaps to come in and set things up for you in the beginning, and possibly to perform backups each week. There are many independent network and server support people who make their living performing this type of work and it should not be difficult to locate a resource. Prices will vary, but working with one of these individuals might cost you US$5,000 to US$10,000 per year and depending on your circumstances, could be a perfect fit. Of course, the On-Demand option at US$30/per user/per month remains an option as well. Specifying your server hardware At home, most of us use our computers as isolated workstations for work or play. A few of us may also connect several computers at home into a network, much in the same manner they are connected at the office. When several computers are connected in a network, there is often value in attaching one or more special computers to the network that is designed to act as a shared resource for all users. These special, typically more powerful computers are called servers. Most of us are familiar enough with a home or office Personal Computer or PC. The usual product is a so-called three-box configuration—the system unit, the display, and the keyboard. While a computer server can look quite similar to a PC, it has a number of fundamental differences relating to hardware that affect cost. Note that there are plenty of low-end servers from the likes of HP and Dell that use non-parity memory, Parallel Advanced Technology Attachment (PATA) or Serial Advanced Technology Attachment (SATA) disk drives, and a single power supply. They can be used for small SugarCRM installations fairly effectively (those not exceeding 10 users). You should, however, always aim for the highest capacity and reliability that you can afford. Remember, it must serve your needs today and in the future, for a minimum of 18 to 24 months. A lower cost solution may seem attractive today, but rarely pays off in the long run. It is usually best to invest a little more in higher quality components up front, rather than pay for problems down the road as they will be more costly. Error Correction Codes (ECC) memory for example, has the ability to detect and correct the most common forms of errors that could be made by semi-conductor memory when it starts to fail. Typical PC memory, by contrast, does not have this capability (due to the lack of a feature called parity) and certainly does not have the ability to correct those errors. The only time a PC checks to see if its memory actually works is at system boot time—when you turn it on. As you intend to leave your server on all the time, that approach clearly will not work. Similarly, power to a server is typically supplied through two physical power supply units connected to it in a redundant manner. Should one unit fail (not uncommon), the fault is reported, but the system continues to function using the working power supply unit. You would then eliminate immediate impact and be allowed the opportunity to replace the power supply at a scheduled maintenance window of time, as opposed to the time of failure. A Redundant Array of Inexpensive Disks (RAID) hard drive configuration is designed to provide performance and redundancy. These types of configurations require the use of multiple hard drives that work in tandem to split data into smaller chunks that in turn reduce access times. There are varying levels of RAID configurations numbered 0 through 6 (skipping 2). The number of drives required to implement a RAID system will vary depending on the level that you select. It can range from two drives (RAID 0) to as many as four (RAID 6). Redundancy levels are also directly tied to the level that you choose. RAID 0 should never be used in a server environment as it does not offer any sort of redundancy. You should look at using RAID 5 or 6, as they offer the best performance and redundancy. A hard drive failure in such environments would not represent a loss of data. RAID 5 and 6 systems are specifically designed to tolerate such problems without causing loss of data. The Central Processing Unit (CPU) or processor used in a server is typically a multi-core processor (at least two cores). Depending on your anticipated load, you might be better off with a quad core chip. The general rule of thumb is that the more cores, the better the performance as computing work would be divided amongst the various cores. System memory size is perhaps the biggest difference between a server and a PC. Most PC users (other than those doing graphics design and other demanding tasks) work happily with 2 to 4 GB of memory in their PC—usually 2 GB is the norm. In contrast, few servers use less than 2 GB of memory, at least those that perform well. Most use a minimum of 4 GB. With more memory, the work being done for many users can stay in memory simultaneously as it is performed, rather than being sent temporarily out to the hard disk if memory runs out of space. As system memory is at least 100 times faster than the hard disk, anything that involves the hard disk will slow down the system substantially. It is also worth noting that database applications, such as SugarCRM, perform better when more memory is made available to the database server. Some of these differences are summarized in the table that follows:   PC Server Form factor Desktop, Tower Tower, Rack mount Memory type Non-parity ECC (Error Checking and Correcting) Memory size 2 GB to 4 GB 4 GB to 32 GB Hard disk technology PATA / SATA SATA / RAID Hard disk speed 5,400 RPM to 10,000 RPM 10,000 RPM to 15,000 RPM LAN interface Ethernet 10/100, Wireless One or more Giga-Ethernet Power supply Single 250 W to 450W Redundant 500W Processor (CPU) Single Dual Core Chip One or more Quad Core Chip Video Often High Performance for Gaming Low Performance / Generic Users One-Local Many-Remote Servers are used for many tasks. A network may have a specific server to act as a database server , for example. That type of server would be optimized for fast and reliable disk storage and high memory capacity. Another server might be an application server— one on which applications are run, with the results being communicated to the users on the PCs using those applications. An application server is typically optimized with lots of memory and CPU power—to get through all that application processing quickly. An example of an application server is a SugarCRM server—the SugarCRM application is actually running on the server—and multiple user PCs are just running web browsers that display web pages. These web pages communicate to the users what is going on in their particular session. For a business with 10 users or less, a SugarCRM server to be used as a combined database and application server should look something like the following: 500 GB of disk space on a RAID 5 configuration 4 GB of ECC memory Two dual core or one quad core CPU A single Gig-Ethernet connection to the network An Uninterruptible Power Supply (UPS) CentOS Linux or Windows Server Standard Edition (32-bit) For a business with perhaps 25 users, the following would be better suited: 1 TB of disk space on a RAID 5 configuration 8 GB of ECC memory Two quad core CPUs A single Gig-Ethernet connection to the network An Uninterruptible Power Supply (UPS) CentOS Linux or Windows Server Standard Edition (64-bit) For a business with 100 users, the server specifications would resemble the following: 2 TB of disk space on a RAID 6 configuration 32 GB of ECC memory Four quad core CPUs Dual Gig-Ethernet connections to the network An Uninterruptible Power Supply (UPS) CentOS Linux (64-bit) or Windows Server Enterprise Edition (32 or 64-bit)

(For more resources on BPEL, SOA and Oracle see here.) If we want our SOA architecture to be highly fexible and agile, we have to ensure loose coupling between different components. As service interfaces and endpoint addresses change over time, we have to remove all point-to-point connections between service providers and service consumers by introducing an intermediate layer—Enterprise Service Bus (ESB). ESB is a key component of every mature SOA architecture and provides several important functionalities, such as message routing, transformation between message types and protocols, the use of adapters, and so on. Another important requirement for providing fexibility is service-reuse. This can be achieved through the use of UDDI (Universal Description, Discovery and Integration) compliant service registry, which enables us to publish and discover services. Using service registry we can also implement dynamic endpoint lookup, so that service consumers retrieve actual service endpoint address from registry in runtime. Oracle Service Bus architecture and features ESB provides means to manage connections, control the communication between services, supervise the services and their SLAs (Service Level Agreements), and much more. The importance of the ESB often becomes visible after the frst development iteration of SOA composite application has taken place. For example, when a service requires a change in its interface or payload, the ESB can provide the transformation capabilities to mask the differences to existing service consumers. ESB can also mask the location of services, making it easy to migrate services to different servers. There are plenty other scenarios, where ESB is important. In this article, we will look at the Oracle Service Bus (OSB). OSB presents a communication backbone for transport and routing of messages across an enterprise. It is designed for high-throughput and reliable message delivery to a variety of service providers and consumers. It supports XML as a native data type, however, other data types are also supported. As an intermediary, it processes incoming service request messages, executes the routing logic and transforms these messages if needed. It can also transform between different transport protocols (HTTP, JMS, File, FTP, and so on.). Service response messages follow the inverse path. The message processing is specifed in the message fow defnition of a proxy service. OSB provides some functionalities that are similar to the functionalities of the Mediator component within the SOA Composite, such as routing, validation, fltering, and transformation. The major difference is that the Mediator is a mediation component that is meant to work within the SOA Composite and is deployed within a SOA composition application. The OSB on the other hand is a standalone service bus. In addition to providing the communication backbone for all SOA (and non-SOA) applications, OSB mission is to shield application developers from changes in the service endpoints and to prevent those systems from being overloaded with requests from upstream applications. In addition to the Oracle Service Bus, we can also use the Mediator service component, which also provides mediation capabilities, but only within SOA composite applications. On the other hand, OSB is used for inter-application communication. The following figure shows the functional architecture of Oracle Service Bus (OSB). We can see that OSB can be categorized into four functional layers: Messaging layer: Provides support to reliably connect any service by leveraging standards, such as HTTP/SOAP, WS-I, WS-Security, WS-Policy, WS-Addressing, SOAP v1.1, SOAP v1.2, EJB, RMI, and so on. It even supports the creation of custom transports using the Custom Transport Software Development Kit (SDK). Security layer: Provides security at all levels: Transport Security (SSL), Message Security (WS-Policy, WS-Security, and so on), Console Security (SSO and role based access) and Policy (leverages WS-Security and WS-Policy). Composition layer: Provides confguration-driven composition environment. We can use either the Eclipse plug-in environment or web-based Oracle Service Bus Console. We can model message fows that contain content-based routing, message validation, and exception handling. We can also use message transformations (XSLT, XQuery), service callouts (POJO, Web Services), and a test browser. Automatic synchronization with UDDI registries is also supported. Management layer: Provides a unifed dashboard for service monitoring and management. We can defne and monitor Service Level Agreements (SLAs), alerts on operation metrics and message pipelines, and view reports. Proxy services and business services OSB uses a specifc terminology of proxy and business services. The objective of OSB is to route message between business services and service consumers through proxy services. Proxy services are generic intermediary web services that implement the mediation logic and are hosted locally on OSB. Proxy services route messages to business services and are exposed to service consumers. A proxy service is confgured by specifying its interface, type of transport, and its associated message processing logic. Message fow defnitions are used to defne the proxy service message handling capabilities. Business services describe the enterprise services that exchange messages with business processes and which we want to virtualize using the OSB. The defnition of a business service is similar to that of a proxy service, however, the business services does not have a message fow defnition. Message fow modeling Message fows are used to defne message processing logic of proxy services. Message fow modeling includes defning a sequence of activities, where activities are individual actions, such as transformations, reporting, publishing and exception management. Message fow modeling can be performed using a visual development environment (Eclipse or Oracle Service Bus Console). Message fow defnitions are defned using components, such as pipelines, branch nodes and route nodes, as shown in the following fgure: A pipeline is a sequence of stages, representing a one-way processing path. It is used to specify message fow for service requests and responses. If a service defnes more operations, a pipeline might optionally branch into operational pipelines. There are three types of pipelines: Request pipelines are used to specify the request path of the message flow Response pipelines are used to specify the response path of a message flow Error pipelines are used as error handlers. Request and response pipelines are paired together as pipeline pairs. Branch nodes are used as exclusive switches, where the processing can follow one of the branches. A variable in the message context is used as a lookup variable to determine which branch to follow. Route nodes are used to communicate with another service (in most cases a business service). They cannot have any descendants in the message fow. When the route node sends the request message, the request processing is fnished. On the other side, when it receives a response message, the response processing begins. Each pipeline is a sequence of stages that contain user-defned message processing actions. We can choose between a variety of supported actions, such as Publish, Service Callout, For Each, If... Then..., Raise Error, Reply, Resume, Skip, Delete, Insert, Replace, Validate, Alert, Log, Report, and more. Later in this article, we will show you how to use a pipeline on the Travel Approval process. However, let us frst look at the Oracle Service Registry, which we will use together with the OSB.

(For more resources on Drupal, see here.) Themes The use of themes makes Drupal exceptionally flexible when it comes to working with the site's interface. Because the functionality of the site is by and large decoupled from the presentation of the site, it is quite easy to chop and change the look, without having to worry about affecting the functionality. This is obviously a very useful feature because it frees you up to experiment, knowing that if worst comes to worst, you can reset the default settings and start from scratch. You can think of a theme as a mask for your site that can be modified in order to achieve virtually any design criteria. Of course, different themes have widely varying attributes, so it is important to find the theme that most closely resembles what you are looking for in order to reduce the amount of work needed to match it to your envisaged design. It is also important to understand that not all downloadable themes are of the same quality. Some are designed better than others. This article utilizes Zen, which is one of the cleanest and most flexible around. Different themes are implemented differently. Some themes use fixed layouts with tables (avoid these because web design should not rely on tables), while others use div tags and CSS (favor these as they are far more flexible and powerful)—you should play around with a variety of themes in order to familiarize yourself with a few different ways of creating a web page. As mentioned, we only have space to cover Zen here, but the lessons learned are easily transferred to other themes with a bit of time and practice. Before we go ahead and look at an actual example, it is important to get an overview of how themes are put together in general. Theme anatomy Drupal themes consist of a set of files that define and control the features of Drupal's web pages (ranging from what functionality to include within a page to how individual page elements will be presented) using PHP, HTML, CSS, and images. Different Drupal 7 template files control different regions of a page, as shown in the following diagram: Looking at how theme files are set up within Drupal hints at the overall process and structure of that theme. Bear in mind that there are several ways to create a working theme, and not all themes make use of template files. However, in the case of the Drupal's default theme setup, we have the following: The left-hand column shows the folders contained within the themes directory. There are a number of standard themes, accompanied by the engines folder that houses a phptemplate.engine file, to handle the integration of templates into Drupal's theming system. Looking at the files present in the garland folder, notice that there are a number of PHP Template files suffixed by tpl.php. These files make use of HTML and PHP code to modify Drupal's appearance. The default versions of these files, which are the ones that would be used in the event a theme had not implemented on its own, can be found in the relevant modules directory. For example, the default comment.tpl.php file is found in modules | comment, and the default page.tpl.php file is located, along with others, in the modules | system folder. Each template file focuses on its specific page element or page, with the noted exception of template.php that is used to override non-standard theme functions—that is, not block, box, comment, node, or page. The themes folder also houses the stylesheets along with images, and in the case of the default theme, colors. Of special interest is the .info file that contains information about the theme to allow Drupal to find and set a host of different parameters. A theme's .info file holds the basic information about a theme that Drupal needs to know, namely, its name, description, features, template regions, CSS files, and JavaScript. Here's Garland's .info file: ; $Id: garland.info,v 1.9 2009/12/01 15:57:40 webchick Exp $name = Garlanddescription = A multi-column theme which can be configured to modifycolors and switch between fixed and fluid width layouts.package = Coreversion = VERSIONcore = 7.xengine = phptemplatestylesheets[all][] = style.cssstylesheets[print][] = print.csssettings[garland_width] = fluid; Information added by drupal.org packaging script on 2010-05-23version = "7.0-alpha5"project = "drupal"datestamp = "1274628610" Note that this file holds, amongst other things: Name—A human-readable theme name Description—A description of the theme Core—The major version of Drupal that the theme is compatible with Stylesheets—Stipulate which stylesheets are to be used by the theme These are not the only types of information that can be held by .info files. As we'll see a bit later on, when it's time to add scripts to a theme, they can be added to the .info file too. To quickly see one way in which .info files can be put to work, look closely at the .info file in the update_test_subtheme theme folder in tests (Below garland): ; $Id: update_test_subtheme.info,v 1.1 2009/10/08 15:40:34 dries Exp $name = Update test subthemedescription = Test theme which uses update_test_basetheme as the basetheme.core = 7.xengine = phptemplatebase theme = update_test_basethemehidden = TRUE; Information added by drupal.org packaging script on 2010-05-23version = "7.0-alpha5"project = "drupal"datestamp = "1274628610" Notice that this contains a base theme directive that is used to specify the parent, or base, theme. A sub-theme shares its parents' code, but modifies parts of it to produce a new look, new functionality, or both. Drupal allows us to create new sub-themes by creating a new folder within the themes directory and specifying the base theme directive in the new theme's .info file—just as we saw in update_test_subtheme. In a nutshell, Drupal provides a range of default themeable functions that expose Drupal's underlying data: such as content and information about that content. Themes can pick and choose which snippets of rendered content they want to override—the most popular method being through the use of PHP template files in conjunction with stylesheets and a .info file. Themes and sub-themes are easily created and modified, provided that you have some knowledge of CSS and HTML—PHP helps if you want to do something more complicated. I should make it clear that this system makes building a new theme fairly easy, provided one knows a bit about PHP. Here's the process: Create a new themes folder in the sites | all folder, and add your new theme folder in there—call it whatever you want (provided it is a unique name) Copy the default template files (or files from any other theme you want to modify) across to the new theme directory, along with any other files that are applicable (such as CSS files) Rewrite the .info file to reflect the attributes and requirements of the new theme, including specifying the base theme directive Modify the layout (this is where your PHP and HTML skills come in handy) and add some flavor with your own stylesheet (included into the new theme through the .info file) Before moving on, there's one small issue of practicality that must be addressed. When it is time for you to begin doing a bit of theme development, bear in mind that there are many types of browser and not all of them are created equal. What this means is that a page that is rendered nicely on one browser might look bad, or worse, not even function properly on another. For this reason, you should: Test your site using several different browsers. The Drupal help site has this to say about browsers: It is recommended you use the Firefox browser with a developer toolbar and view the formatted sources' extensions. I wholeheartedly agree. You can obtain a copy of the Firefox browser at www.mozilla.com/firefox. Firefox should also be extended with Firebug, which is an extremely useful tool for client-side web debugging: https://addons.mozilla.org/en-US/firefox/addon/1843/. Choosing a base theme As discussed, Drupal ships with a few default themes, and there are quite a few more available in the Downloads section of the Drupal site. Looking at how Drupal presents its core Themes page under Appearance in the toolbar menu, we can see the following: Any new themes that are added to the site will be used to enable, disable, configure, or set as a default from this page. Be aware that some themes might not implement functionality that is important to your site. Ensure that you test each theme thoroughly before allowing users to select it. Enabling the Stark theme, and setting it as the default theme, causes the site, which has been presented in the standard Garland theme up until now, to look something like this: This is a vast change from the previous look. Notice too that the entire layout of the site has changed—there are no well defined columns, no visually defined header section, and so on. In addition, the previous fonts and colors have also been demolished. Take the time to view each theme that is available by default in order to get a feel for how different themes can produce wildly differing looks and layouts. That is not the end of the story, because the Drupal site also has a whole bunch of themes for us to explore. So head on over to the themes page at http://drupal.org/project/themes and select the relevant version tab to bring up the themes that are available. You have already seen how to download and install other modules, and the process for installing themes is no different—download and extract the contents of the desired theme to the themes folder in sites | default or sites | all. For example, the Zen theme was downloaded and extracted, and provides us with a new option in the list of themes (some downloads will provide a number of sub-themes too), as shown in the following screenshot: Enable and set default causes the site to look like the next screenshot: Notice that while the color scheme is effectively non-existent, the page has retained its overall structure in that it has defined sidebars, a header region, and a central content region. Before we begin customizing this, let's take a look at the configuration settings for this theme.

  Apache OfBiz Cookbook Over 60 simple but incredibly effective recipes for taking control of OFBiz Optimize your OFBiz experience and save hours of frustration with this timesaving collection of practical recipes covering a wide range of OFBiz topics. Get answers to the most commonly asked OFBiz questions in an easy-to-digest reference style of presentation. Discover insights into OFBiz design, implementation, and best practices by exploring real-life solutions. Each recipe in this Cookbook is crafted to describe not only "how" to accomplish a specific task, but also "why" the technique works to ensure you get the most out of your OFBiz implementation. Read more about this book (For more resources on Apache see here.) Introduction Ask five people what "web services" are and you will likely get at least six different opinions. Because the term evokes such ambiguity, we need to set ground rules for this article and define what we mean by "web services". Therefore, for the purposes of this book, "web services" are the interactive exchange of messages from one system to another using the Internet as the network transport and HTTP/HTTPS as the messaging protocol. Message exchange transpires without human intervention and may be one-way—that is, called without an immediate response expected—or two-way. Web services operate as producer/consumer systems where the producer—called the "service provider"—offers one or more "services" to the "consumer"—sometimes referred to as the "client". In the web services world, Internet-based service providers advertise and deliver service from locations throughout the Web. The Internet, and the Web in particular, serve as the highway over which potential web service clients travel to find service providers, make contact, and deliver products. Service-oriented by design, OFBiz is a natural for building and deploying both web service clients and web service providers. Any OFBiz web application (webapp) may both consume web services and act as a web service provider within the same application or in an unlimited number of OFBiz webapps. Within the web service producer/consumer model, service providers are responsible for accepting and validating requests for service and delivering the product. Consumers must find service providers, request service, and accept delivery of the product. There are a number of ad-hoc and formal standards that have evolved over the last few years to help facilitate the business of enabling web services, including, but not limited to, URL parameter passing, XML-RPC, and Simple Object Access Protocol (SOAP) based messaging. OFBiz provides builtin support with tools and integration points to make implementing both service provider and consumer web services a snap. Requesting web services using URL parameters There are many web service providers that require nothing more than URL parameter passing to request a service. These service providers take HTTP/HTTPS request parameters as appended to a prospective consumer's URL, and process requests according to the passed parameter values. Services are delivered back to the requestor through the client's HTTP/ HTTPS response message or as a separate HTTP/HTTPS request message exchange. An example of such a real world web service is the PayPal Payments Standard payment processing service . This web service expects requests to come in on an advertised URL with request particulars appended to the URL as request parameters. Prospective consuming systems send HTTP/HTTPS request messages to the PayPal URL asking for service. Once a request for service has been accepted by PayPal, the Payments Standard web service responds and delivers service using the HTTP/HTTPS response message. A separate web service, also involving PayPal, called the Instant Payment Notification (IPN) web service is an example of a web service in which parameters are passed on the URL from the service provider to a consumer such as OFBiz. In this case, OFBiz listens on a configured URL for an HTTP/HTTPS request message from PayPal. When one is received, OFBiz responds appropriately, taking delivery of PayPal service. Note: to implement a PayPal IPN client within an OFBiz web application, you must provide PayPal a destination URL that maps to a valid OFBiz request-map, and then process any incoming URL parameters according to the PayPal IPN directions. Getting ready To act as a web service client and pass parameters on the URL within an OFBiz Java Event or Service, make sure you include the following Java packages in your program: import java.io.IOException;import java.net.URL;import java.net.URLConnection;import javax.Servlet.http.HttpServletRequest;import javax.servlet.http.HttpServletResponse; How to do it... To request a service using URL parameters, follow these steps: Within an existing OFBiz Java program (either an Event, Service, or any other) method, create a Java HashMap containing the name/value pairs that you wish to pass on the URL. For example: Map parameters = UtilMisc.toMap("param1", "A", "param2", "B"); Use the OFBiz-provided UtilHttp.urlEncodeArgs method to properly encode the parameters directly from the HashMap into a Java String. For example: String encodedParameters = UtilHttp.urlEncodeArgs(parameters, false); Build a URL and add the encoded parameter string to the URL: String redirectUrl = "http://www.somehost.com";String redirectString = redirectUrl + "?" + encodedParameters; Send the request by way of the HttpServletResponse object's redirect method: try { response.sendRedirect(redirectString); } catch (IOException e) {// process errors here return "error";} How it works... In a very simple web service client scenario, OFBiz acts on behalf of a user or another OFBiz process and makes a web service consumer request of a remote service provider. The request is sent using a HTTP/HTTPS request message with one or more service parameters appended to the URL. The URL is the location on the web of the service provider. Because the scenario described above is a one-way message exchange—that is, the request message is delivered to the destination URL, but OFBiz does not wait around for a response message—there must be assumptions made about how the web service provider will deliver service. Many times, service is delivered through a totally separate message exchange, initiated by first making the one-way request as described earlier. To illustrate how this may play out, we consider the PayPal Payments Standard web service. This web service may be invoked from OFBiz in at least two different ways. For example, one approach is to include an HTML form on an OFBiz web page with a Submit button. The Submit button when clicked redirects the browser (with the request message) to the PayPal web service site passing the form contents as is. An alternative implementation is to have an HTML form on an OFBiz web page with a Submit button that, when clicked, forwards the browser's request of an OFBiz Service (or Event). In this case, the OFBiz Event or Service will take the form attribute values (from the request message) and create a URL for the PayPal web service location. The original form attribute values and any other information as provided by the context or through database reads is appended to the URL. OFBiz then redirects the user's original request message using the sendRedirect method on the HttpServletResponse object to effectively send the user, by way of a browser and an appropriately crafted URL, to the PayPal web service. Building URL request parameters out of plain Java strings can be tricky given the nature of the characters used to construct request parameters and delimit multiple parameter strings. For example, how do you pass a space character as part of a parameter when spaces are used as delimiters? Enter URL encoding. URL encoding takes certain characters, deemed "special" characters, and "escapes" them so that they may be used as part of a request parameter string. OFBiz provides an easy-to-use encoder (and decoder) method(s): the UrlEncodeArgs method on the UtilHttp utility that takes as an argument a Java Map and returns an encoded string that may then be appended to a URL as shown earlier. Note: an exhaustive treatment of URL encoding is beyond the scope of this article. For more information on HTML and ASCII character codes and encoding symbols, please see the HTML Codes page There's more... The UrlEncodeArgs method has two modes of operation: selecting the false method-parameter value will encode using only an ampersand (&) symbol while the true parameter value tells OFBiz to use &amp as the encoding string. Based on the web service provider's instructions, you will need to determine which mode is appropriate for your application. Many web services do not require encoded values. You will need to verify for each service whether or not it is necessary to encode and decode URL parameters. For example, the PayPal IPN web service sends request parameters without any encoding. When returning IPN messages, the client web service is, however, instructed to encode parameters. PayPal IPN is strictly a server-to-server (there is no human intervention) messaging system where message traffic is transported across the web from one server URL to another. PayPal is the web service provider while, in this scenario, OFBiz acts as the web service client. It works something like shown in the following diagram: Requesting web services using an HttpClient Many web services are implemented using HTTP/HTTPS request methods and parameters passed as part of the request's message body. These requests for service mimic a user sitting at a browser submitting HTML forms and waiting for server response. Service providers read HTTP/HTTPS request header information and name/value request message parameter pairs, and deliver service through the HTTP/HTTPS response message. Writing clients for these types of web services usually require a synchronous call to the service provider. From within your OFBiz client code, you initiate a call to a service provider and then wait until a response (or timeout) is received. Unlike the PayPal Payments Standard service described earlier, the OFBiz client program does not redirect HTTP/HTTPS request messages to another URL. There are a number of examples within the out-of-the-box OFBiz project of service providers that use the HTTP/HTTPS request message body to exchange information with OFBiz clients. They include, but are not limited to: Authorize.net Payment Services ClearCommerce Payment Services Go Software RiTA ValueLink Prepaid/Gift Card Payment Services DHL, FedEx, United Parcel Services (UPS), and United States Post Office Shipping Services CDYNE Web Based Services PayPal Payments Pro Getting ready The first step in writing any web service client is to gather the following information about how the target web service operates: The URL on the web for the service provider Any connection parameters and/or HTTP/HTTPS request message header settings that must be passed as required by the service provider The HTTP/HTTPS connection verb (get, post, or other) Within a Java program, to send and receive web service messages as a client and use the built-in HTTP client utility provided by OFBiz, make sure you have the following Java packages imported in your program: import org.ofbiz.base.util.HttpClient;import org.ofbiz.base.util.HttpClientException; How to do it... You can request a web service by following these steps: Create a connection string that includes the URL of the target web service and the type of request: String connectString = "http://www.some_web_service_url.com/serviceName"; Within your Java program, create an instance of the HttpClient object with the URL/connection string passed to the constructor as shown here: HttpClient http = new HttpClient(connectString); Create the content of your request as dictated by the target web service provider. For example, some web services expect XML documents; others, simple string parameters. A web service that expects a string of name/value pairs could be coded as follows: http.setParameter("Param1", "X");http.setParameter("Param2", "Y"); Send your request using the appropriate method on the HttpClient object. For "get" requests, use the get method. For "post" requests, use the post method as shown here: try { response = http.post();}catch (HttpClientException e) { // Process error conditions here} Handle any service response inline. Unlike the asynchronous nature of the PayPal IPN web service described earlier, HttpClient based web services process return calls inline with the initial web service call. Under the covers, the HttpClient utility handles all the network connection set up and lower-level message transmissions. There is no need to release or close the connection as OFBiz manages the handoff of connections. How it works... When using the HttpClient to access web services remote to OFBiz, you send the consumer-side call synchronously; that is, you wait for the return from the remote web service call within your program. The OFBiz integration of the HttpClient utility manages the details necessary to open the network connection, maintain direct request and response message exchanges, and close the connection upon completion of processing. There's more... The OFBiz implementation of the HttpClient object provides several convenience constructors, which may be useful depending on your processing needs. These include: // To create a new client object and connect using a URL object instead of a StringURL url = "https://www.some_host.com/";HttpClient http = new HttpClient(url);// To create a new client object using a Java Map containing request parametersHttpClient http = new HttpClient(url, UtilMisc.toMap("param1", "X", "param2", "Y");//To create a new client object with a parameter map and header settingsHttpClient http = new HttpClient(connectString, UtilMisc.toMap("param1", "X"), UtilMisc.toMap("User-Agent, "Mozilla/4.0")); See also OFBiz provides an integration of the Apache HttpClient software package: the Jakarta Commons HTTP Client that is accessed by creating a new HttpClient object. Any method you can call on, the original Apache HttpClient object is available in the OFBiz implementation. This includes full support for HTTPS (SSL) clients. For more information, please see the Jakarta Commons HTTP Client web page

(For more resources on Oracle, see here.) Business Process Management and SOA One of the major benefits of a Service-Oriented Architecture is its ability to align IT with business processes. Business processes are important because they define the way business activities are performed. Business processes change as the company evolves and improves its operations. They also change in order to make the company more competitive. Today, IT is an essential part of business operations. Companies are simply unable to do business without IT support. However, this places a high level of responsibility on IT. An important part of this responsibility is the ability of IT to react to changes in a quick and efficient manner. Ideally, IT must instantly respond to business process changes. In most cases, however, IT is not flexible enough to adapt application architecture to the changes in business processes quickly. Software developers require time to modify application behavior. In the meantime, the company is stuck with old processes. In a highly competitive marketplace such delays are dangerous, and the threat is exacerbated by a reliance on traditional software development to make quick changes within an increasingly complex IT architecture. The major problem with traditional approaches to software development is the huge semantic gap between IT and the process models. The traditional approach to software development has been focused on functionalities rather than on end-to-end support for business processes. It usually requires the definition of use cases, sequence diagrams, class diagrams, and other artifacts, which bring us to the actual code in a programming language such as Java, C#, C++, and so on. SOA reduces the semantic gap by introducing a development model that aligns the IT development cycle with the business process lifecycle. In SOA, business processes can be executed directly and integrated with existing applications through services. To understand this better, let's look at the four phases of the SOA lifecycle: Process modeling: This is the phase in which process analysts work with process owners to analyze the business process and define the process model. They define the activity flow, information flow, roles, and business documents. They also define business policies and constraints, business rules, and performance measures. Performance measures are often called Key Performance Indicators (KPIs). Examples of KPIs include activity turnaround time, activity cost, and so on. Usually Business Process Modeling Notation (BPMN) is used in this phase. Process implementation: This is the phase in which developers work with process analysts to implement the business process, with the objective of providing end-to-end support for the process. In an SOA approach, the process implementation phase includes process implementation with the Business Process Execution Language (BPEL) and process decomposition to the services, implementation or reuse of services, and integration. Process execution and control: This is the actual execution phase, in which the process participants execute various activities of the process. In the end-to-end support for business processes, it is very important that IT drives the process and directs process participants to execute activities, and not vice versa, where the actual process drivers are employees. In SOA, processes execute on a process server. Process control is an important part of this phase, during which process supervisors or process managers control whether the process is executing optimally. If delays occur, exceptions arise, resources are unavailable, or other problems develop, process supervisors or managers can take corrective actions. Process monitoring and optimization: This is the phase in which process owners monitor the KPIs of the process using Business Activity Monitoring (BAM). Process analysts, process owners, process supervisors, and key users examine the process and analyze the KPIs while taking into account changing business conditions. They examine business issues and make optimizations to the business process. The following figure shows how a process enters this cycle, and goes through the various stages: Once optimizations have been identified and selected, the process returns to the modeling phase, where optimizations are applied. Then the process is re-implemented and the whole lifecycle is repeated. This is referred to as an iterative-incremental lifecycle, because the process is improved at each stage. Organizational aspects of SOA development SOA development, as described in the previous section, differs considerably from traditional development. SOA development is process-centric and keeps the modeler and the developer focused on the business process and on end-to-end support for the process, thereby efficiently reducing the gap between business and IT. The success of the SOA development cycle relies on correct process modeling. Only when processes are modeled in detail can we develop end-to-end support that will work. Exceptional process fl ows also have to be considered. This can be a difficult task, one that is beyond the scope of the IT department (particularly when viewed from the traditional perspective). To make process-centric SOA projects successful, some organizational changes are required. Business users with a good understanding of the process must be motivated to actively participate in the process modeling. Their active participation must not be taken for granted, lest they find other work "more useful," particularly if they do not see the added value of process modeling. Therefore, a concise explanation as to why process modeling makes sense can be a very valuable time investment. A good strategy is to gain top management support. It makes enormous sense to explain two key factors to top management—first, why a process centric approach and end-to-end support for processes makes sense, and second, why the IT department cannot successfully complete the task without the participation of business users. Usually top management will understand the situation rather quickly and will instruct business users to participate. Obviously, the proposed process-centric development approach must become an ongoing activity. This will require the formalization of certain organizational structures. Otherwise, it will be necessary to seek approval for each and every project. We have already seen that the proposed approach outgrows the organizational limits of the IT department. Many organizations establish a BPM/SOA Competency Center, which includes business users and all the other profiles required for SOA development. This also includes the process analyst, process implementation, service development, and presentation layer groups, as well as SOA governance. Perhaps the greatest responsibility of SOA development is to orchestrate the aforementioned groups so that they work towards a common goal. This is the responsibility of the project manager, who must work in close connection with the governance group. Only in this way can SOA development be successful, both in the short term (developing end-to-end applications for business processes), and in the long term (developing a fl exible, agile IT architecture that is aligned with business needs). Technology aspects of SOA development SOA introduces technologies and languages that enable the SOA development approach. Particularly important is BPMN, which is used for business process modeling, and BPEL, which is used for business process execution. BPMN is the key technology for process modeling. The process analyst group must have in-depth knowledge of BPMN and process modeling concepts. When modeling processes for SOA, they must be modeled in detail. Using SOA, we model business processes with the objective of implementing them in BPEL and executing them on the process server. Process models can be made executable only if all the relevant information is captured that is needed for the actual execution. We must identify individual activities that are atomic from the perspective of the execution. We must model exceptional scenarios too. Exceptional scenarios define how the process behaves when something goes wrong—and in the real world, business processes can and do go wrong. We must model how to react to exceptional situations and how to recover appropriately. Next, we automate the process. This requires mapping of the BPMN process model into the executable representation in BPEL. This is the responsibility of the process implementation group. BPMN can be converted to BPEL almost automatically and vice versa, which guarantees that the process map is always in sync with the executable code. However, the executable BPEL process also has to be connected with the business services. Each process activity is connected with the corresponding business service. Business services are responsible for fulfilling the individual process activities. SOA development is most efficient if you have a portfolio of business services that can be reused, and which includes lower-level and intermediate technical services. Business services can be developed from scratch, exposed from existing systems, or outsourced. This task is the responsibility of the service development group. In theory, it makes sense for the service development group to first develop all business services. Only then would the process implementation group start to compose those services into the process. However, in the real world this is often not the case, because you will probably not have the luxury of time to develop the services first and only then start the processes. And even if you do have enough time, it would be difficult to know which business services will be required by processes. Therefore, both groups usually work in parallel, which is a great challenge. It requires interaction between them and strict, concise supervision of the SOA governance group and the project manager; otherwise, the results of both groups (the process implementation group and the service development group) will be incompatible. Once you have successfully implemented the process, it can be deployed on the process server. In addition to executing processes, a process server provides other valuable information, including a process audit trail, lists of successfully completed processes, and a list of terminated or failed processes. This information is helpful in controlling the process execution and in taking any necessary corrective measures. The services and processes communicate using the Enterprise Service Bus (ESB). The services and processes are registered in the UDDI-compliant service registry. Another part of the architecture is the rule engine, which serves as a central place for business rules. For processes with human tasks, user interaction is obviously important, and is connected to identity management. The SOA platform also provides BAM. BAM helps to measure the key performance indicators of the process, and provides valuable data that can be used to optimize processes. The ultimate goal of each BAM user is to optimize process execution, to improve process efficiency, and to sense and react to important events. BAM ensures that we start optimizing processes where it makes most sense. Traditionally, process optimization has been based on simulation results, or even worse, by guessing where bottlenecks might be. BAM, on the other hand, gives more reliable and accurate data, which leads to better decisions about where to start with optimizations. The following figure illustrates the SOA layers:

  Apache OfBiz Cookbook Over 60 simple but incredibly effective recipes for taking control of OFBiz Optimize your OFBiz experience and save hours of frustration with this timesaving collection of practical recipes covering a wide range of OFBiz topics. Get answers to the most commonly asked OFBiz questions in an easy-to-digest reference style of presentation. Discover insights into OFBiz design, implementation, and best practices by exploring real-life solutions. Each recipe in this Cookbook is crafted to describe not only "how" to accomplish a specific task, but also "why" the technique works to ensure you get the most out of your OFBiz implementation. Read more about this book (For more resources on Apache see here.) Introduction OFBiz has been characterized as having an "event-driven, service-oriented architecture". Long before it was fashionable to build complex enterprise computer systems using service-oriented techniques, OFBiz implemented a number of architectural features enabling a service-oriented design. These features include: A context-aware Service Engine available for use across the entire framework or, if configured, externally through supported network interfaces. OFBiz Service consumers need not concern themselves with the location of the called Service nor with a Service's implementation details. OFBiz handles all that transparently to both the service provider and consumer. Multiple invocation methods including: inline or synchronous with the calling program; out-of-band or asynchronous from the caller's processing logic and/or as a scheduled job for recurring execution. OFBiz handles all input, output, and context parameter transfers seamlessly to both Service provider and Service caller. Chaining of Services for a true, event-driven Service platform and implementation of complex workflows. Services may be configured to be invoked based on external events or triggers. Once triggered, an OFBiz Service may call other Service(s) based on additional triggering Events and/or conditions. Any combination of Services may be chained together to form Service Event Condition Action(s) or SECAs. A fully integrated job scheduler for recurring and single use asynchronous job scheduling. The OFBiz job scheduler handles all the mundane coordination tasks associated with job scheduling, including calendar lookups, frequency, and interval timing. Service creation and implementation tools, including selectable input and output validations based on configured parameter types; authentication and authorization checks integrated with OFBiz user login processing, and even localization preservation across Service calls. The heart of the OFBiz service-oriented implementation is the Service Engine factory. Using a factory pattern, OFBiz provides an easily extendable Service management and invocation tool supporting any number of concurrent Services and any number of third-party execution engines including, but not limited to: Java, Groovy, Javascript, JPython, and the OFBiz "simple" Service (based on the OFBiz Mini-Language.) By offloading Service implementation to programming language-specific engines, OFBiz Services may be written and implemented in any language that suits the developer's fancy. The Service Engine factory may be called from anywhere in the framework to handle the details of Service invocation, as shown in the following diagram: Managing existing OFBiz Services Out-of-the-box OFBiz comes with many hundreds of Services. To find and otherwise manage OFBiz Services, a fully featured Service management dashboard is provided. Privileged users may conveniently handle all Service related tasks using the OFBiz WebTools toolkit as described. How to do it... To access the OFBiz Service management main web page, navigate to the following WebTools URL: https://localhost:8443/webtools/control/ServiceList When prompted for a username and password, login as the administrative user (username "admin", password "ofbiz"). How it works... WebTools provides a dashboard-like UI to view, manage, run, and support OFBiz Services. The main web page for OFBiz Service support is found at: https://localhost:8443/webtools/ServiceList (Note the use of case-sensitive addressing). This web page is shown in the following figure: There's more... Asynchronous and scheduled Service requests are managed by the OFBiz job scheduler. The job scheduler consists of multiple execution threads as configured in the ~framework/ service/config/serviceengine.xml file. Threads run from one or more thread "pools". From the OFBiz Thread List web page, you may see at a glance the configuration of the OFBiz job scheduler as well as thread and thread pool usage as shown here: Calling a Service from an HTML form Services may be called directly from HTML forms by setting the HTML form's action element to point to the URL of a controller.xml request-map that resolves to either an OFBiz Event that calls a Service or directly to a Service. To demonstrate this, the following section uses the WebTool's Run Service HTML form to invoke a Service. Getting ready For the purposes of this recipe, we shall use an existing Service called testScv and invoke it from the WebTools UI. In this example, we will not be creating an HTML form nor creating a Service, but rather using an existing form and Service: To view the results of the testScv Service's execution, open an OFBiz console window from the command line Alternatively, to view the results of the execution, run the Unix tail command tail -f ofbiz.log on the ofbiz.log file ~runtime/ofbiz.log while performing this recipe How to do it... Services may be called directly from HTML forms by following these steps: Navigate directly to the Run Service WebTools web page by selecting the Run Service URL: ~webtools/control/runService. From the Run Service form, enter in testScv in the field labeled Service. Leave the field labeled Pool as is. Hit the Submit button to bring up the Schedule Job web page. On the Schedule Job web page, enter in any values for the requested form fields. These fields correspond to any Service INPUT parameters as configured in the Service definition for testScv. Hit the Submit button. The testScv has been called by using an HTML form. To verify that the input parameters entered in step 6 earlier are processed by the testScv, inspect the ofbiz.log file as shown: How it works... Any OFBiz Service may be called from an OFBiz webapp HTML form simply by: Creating an HTML form with an action attribute URL for the target Service. Creating a controller.xml entry with a request-map for the target Service that matches the HTML form's action URL. For example, the HTML form for the Run Service tool has an action value as shown in the following code snippet: <form name= "scheduleForm" method= "POST" action= "/webtools/control/scheduleService" /> <input type="text" name="testScv" /> <!-- Stuff Intentionally Removed ></form> When the form is submitted, the URL set within the form's action (webtools/control/scheduledService) is intercepted by the WebTools controller servlet, which consults its controller.xml file to determine how to handle this request. The controller.xml entry for this URL is shown here: <request-map uri="scheduleService"> <security https="true" auth="true"/> event type="java" path="org.ofbiz.webapp.event.CoreEvents" invoke="scheduleService"/> <response name="success" type="view" value="FindJob"/> <response name="sync_success" type="view" value="serviceResult"/> <response name="error" type="view" value="scheduleJob"/></request-map> The URL request is mapped to an OFBiz Event called scheduleService. Inside the scheduleService Event, a call is made to the Service Engine to invoke testScv using the Java Service implementation engine as shown in the testScv Service definition file: <service name="testScv" engine="java" export="true" validate="false" require-new-transaction="true" location="org.ofbiz.common.CommonServices" invoke="testScv"> <description>Test service</description> <attribute name="defaultValue" type="Double" mode="IN" default-value="999.9999"/> <attribute name="message" type="String" mode="IN" optional="true"/> <attribute name="resp" type="String" mode="OUT"/></service> After testScv has been executed, processing control returns to the OFBiz request handler (part of the controller servlet) and then back to the calling webapp as configured in the controller.xml file. Calling asynchronous Services from HTML forms You can use WebTools and HTML forms to run a Service asynchronously either one time or on a recurring basis. The following demonstrates the steps necessary to schedule testScv to be executed one time, asynchronously, as a scheduled job. Getting ready Navigate directly to the Schedule Job web page. ~https://localhost:8443/webtools/control/scheduleJob How to do it... To execute testScv asynchronously follow, these steps: In the Service form field, enter in testScv as shown in the screenshot. Leave the Job field empty. OFBiz will pick a unique name automatically. Use the calendar pop-up icon directly next to the Start Date/Time field to select any date and time after the current wall clock time. Submit this form by clicking the Submit button to bring up the Service Parameters form, which allows the caller to provide alternative input parameters to the Service. Add INPUT parameters as shown: Submit the Service Parameters form. testScv will be scheduled to run at the specified time. How it works... Scheduled Services are run asynchronously from the calling program. As such, requests for scheduling are handled by the OFBiz job scheduler. Each scheduled Service is assigned a unique job identifier (jobId) and execution pool by the job scheduler. After the Service is scheduled for execution, control returns to the calling program. There's more... Using the OFBiz job scheduler Job List web page, you may find all scheduled jobs. In the following screenshot, testScv is shown as scheduled for execution on the Job List Search Results web page as specified in the recipe: Because the testScv only writes output to the logfile, we may verify successful execution and scheduling by observing the ofbiz.log runtime logfile as shown: Calling a Service many times from an HTML form It is possible to call a Service multiple times from a single HTML form (for example, one time for each row in the form) by placing a line similar to the following with a service-multi event type defined for the controller.xml request-map entry of the target Service. How to do it... Follow these steps to call a Service multiple times: Use the event type service-multi within the controller.xml request-map entry as shown here: <request-map uri="someService" /> <event type="service-multi" invoke="someService"/> <!-- Other request-map statements intentionally left out --></request-map> If using an OFBiz Form Widget, add a line similar to the following to the Form Widget definition. Note, the list-name is the name of the list that is generating multiple rows for the HTML form: <form name="someFormName" type="multi" use-row-submit="true" list-name="someList" target="someServiceName" / <!-- Form fields removed for reading clarity --></form> If using a FreeMarker template, add lines similar to the following: <form name="mostrecent" mode="POST" action="<@ofbizUrl>someService</@ofbizUrl>"/> <#assign row=0/> <#list someList as listItem> <#-- HTML removed for reading clarity. Each row has a unique input name associated with it allowing this single Form to be submitted to the "someServiceName" Service from each row --> <input type="radio" name="someFormField_o_${row}" value="someValue" checked/> <input type="radio" name="someFormField_o_${row}" value="someValue"/> </#list></form> How it works... The Event type service-multi provides a convenient shortcut for coding HTML forms that are embedded within lists. Each list item is automatically converted to a unique form field so that a single Service may be called from any row within the list.

(For more resources on Solr, see here.) The classic plugin for Rails is acts_as_solr that allows Rails ActiveRecord objects to be transparently stored in a Solr index. Other popular options include Solr Flare and rsolr. An interesting project is Blacklight, a tool oriented towards libraries putting their catalogs online. While it attempts to meet the needs of a specific market, it also contains many examples of great Ruby techniques to leverage in your own projects. You will need to turn on the Ruby writer type in solrconfig.xml: <queryResponseWriter name="ruby" class="org.apache.solr.request.RubyResponseWriter"/> The Ruby hash structure has some tweaks to fit Ruby, such as translating nulls to nils, using single quotes for escaping content, and the Ruby => operator to separate key-value pairs in maps. Adding a wt=ruby parameter to a standard search request returns results in a Ruby hash structure like this: { 'responseHeader'=>{ 'status'=>0, 'QTime'=>1, 'params'=>{ 'wt'=>'ruby', 'indent'=>'on', 'rows'=>'1', 'start'=>'0', 'q'=>'Pete Moutso'}}, 'response'=>{'numFound'=>523,'start'=>0,'docs'=>[ { 'a_name'=>'Pete Moutso', 'a_type'=>'1', 'id'=>'Artist:371203', 'type'=>'Artist'}]}} acts_as_solr A very common naming pattern for plugins in Rails that manipulate the database backed object model is to name them acts_as_X. For example, the very popular acts_as_list plugin for Rails allows you to add list semantics, like first, last, move_next to an unordered collection of items. In the same manner, acts_as_solr takes ActiveRecord model objects and transparently indexes them in Solr. This allows you to do fuzzy queries that are backed by Solr searches, but still work with your normal ActiveRecord objects. Let's go ahead and build a small Rails application that we'll call MyFaves that both allows you to store your favorite MusicBrainz artists in a relational model and allows you to search for them using Solr. acts_as_solr comes bundled with a full copy of Solr 1.3 as part of the plugin, which you can easily start by running rake solr:start. Typically, you are starting with a relational database already stuffed with content that you want to make searchable. However, in our case we already have a fully populated index available in /examples, and we are actually going to take the basic artist information out of the mbartists index of Solr and populate our local myfaves database with it. We'll then fire up the version of Solr shipped with acts_as_solr, and see how acts_as_solr manages the lifecycle of ActiveRecord objects to keep Solr's indexed content in sync with the content stored in the relational database. Don't worry, we'll take it step by step! The completed application is in /examples/8/myfaves for you to refer to. Setting up MyFaves project We'll start with the standard plumbing to get a Rails application set up with our basic data model: >>rails myfaves>>cd myfaves>>./script/generate scaffold artist name:string group_type:string release_date:datetime image_url:string>>rake db:migrate This generates a basic application backed by an SQLite database. Now we need to install the acts_as_solr plugin. acts_as_solr has gone through a number of revisions, from the original code base done by Erik Hatcher and posted to the solr-user mailing list in August of 2006, which was then extended by Thiago Jackiw and hosted on Rubyforge. Today the best version of acts_as_solr is hosted on GitHub by Mathias Meyer at http://github.com/ mattmatt/acts_as_solr/tree/master. The constant migration from one site to another leading to multiple possible 'best' versions of a plugin is unfortunately a very common problem with Rails plugins and projects, though most are settling on either RubyForge.org or GitHub.com. In order to install the plugin, run:  >>script/plugin install git://github.com/mattmatt/acts_as_solr.gitt We'll also be working with roughly 399,000 artists, so obviously we'll need some page pagination to manage that list, otherwise pulling up the artists /index listing page will timeout:  >>script/plugin install git://github.com/mislav/will_paginate.git Edit the ./app/controllers/artists_controller.rb file, and replace in the index method the call to @artists = Artist.find(:all) with: @artists = Artist.paginate :page => params[:page], :order => 'created_at DESC' Also add to ./app/views/artists/index.html.erb a call to the view helper to generate the page links: <%= will_paginate @artists %> Start the application using ./script/server, and visit the page http://localhost:3000/artists/. You should see an empty listing page for all of the artists. Now that we know the basics are working, let's go ahead and actually leverage Solr. Populating MyFaves relational database from Solr Step one will be to import data into our relational database from the mbartists Solr index. Add the following code to ./app/models/artist.rb: class Artist < ActiveRecord::Base acts_as_solr :fields => [:name, :group_type, :release_date]end The :fields array of hashes maps the attributes of the Artist ActiveRecord object to the artist fields in Solr's schema.xml. Because acts_as_solr is designed to store data in Solr that is mastered in your data model, it needs a way of distinguishing among various types of data model objects. For example, if we wanted to store information about our User model object in Solr in addition to the Artist object then we need to provide a type_field to separate the Solr documents for the artist with the primary key of 5 from the user with the primary key of 5. Fortunately the mbartists schema has a field named type that stores the value Artist, which maps directly to our ActiveRecord class name of Artist and we are able to use that instead of the default acts_as_solr type field in Solr named type_s. There is a simple script called populate.rb at the root of /examples/8/myfaves that you can run that will copy the artist data from the existing Solr mbartists index into the MyFaves database: >>ruby populate.rb populate.rb is a great example of the types of scripts you may need to develop to transfer data into and out of Solr. Most scripts typically work with some sort of batch size of records that are pulled from one system and then inserted into Solr. The larger the batch size, the more efficient the pulling and processing of data typically is at the cost of more memory being consumed, and the slower the commit and optimize operations are. When you run the populate.rb script, play with the batch size parameter to get a sense of resource consumption in your environment. Try a batch size of 10 versus 10000 to see the changes. The parameters for populate.rb are available at the top of the script: MBARTISTS_SOLR_URL = 'http://localhost:8983/solr/mbartists'BATCH_SIZE = 1500MAX_RECORDS = 100000 # the maximum number of records to load, or nil for all There are roughly 399,000 artists in the mbartists index, so if you are impatient, then you can set MAX_RECORDS to a more reasonable number. The process for connecting to Solr is very simple with a hash of parameters that are passed as part of the GET request. We use the magic query value of *:* to find all of the artists in the index and then iterate through the results using the start parameter: connection = Solr::Connection.new(MBARTISTS_SOLR_URL) solr_data = connection.send(Solr::Request::Standard.new({ :query => '*:*', :rows=> BATCH_SIZE, :start => offset, :field_list =>['*','score'] })) In order to create our new Artist model objects, we just iterate through the results of solr_data. If solr_data is nil, then we exit out of the script knowing that we've run out of results. However, we do have to do some parsing translation in order to preserve our unique identifiers between Solr and the database. In our MusicBrainz Solr schema, the ID field functions as the primary key and looks like Artist:11650 for The Smashing Pumpkins. In the database, in order to sync the two, we need to insert the Artist with the ID of 11650. We wrap the insert statement a.save! in a begin/rescue/end structure so that if we've already inserted an artist with a primary key, then the script continues. This just allows us to run the populate script multiple times: solr_data.hits.each do |doc| id = doc["id"] id = id[7..(id.length)] a = Artist.new(:name => doc["a_name"], :group_type => a["a_type"], :release_date => doc["a_release_date_latest"]) a.id = id begin a.save! rescue ActiveRecord::StatementInvalid => ar_si raise ar_si unless ar_si.to_s.include?("PRIMARY KEY must be unique") #sink duplicates endend Now that we've transferred the data out of our mbartists index and used acts_as_solr according to the various conventions that it expects, we'll change from using the mbartists Solr instance to the version of Solr shipped with acts_as_solr. Solr related configuration information is available in ./myfaves/config/solr.xml. Ensure that the default development URL doesn't conflict with any existing Solr's you may be running: development: url: http://127.0.0.1:8982/solr Start the included Solr by running rake solr:start. When it starts up, it will report the process ID for Solr running in the background. If you need to stop the process, then run the corresponding rake task: rake solr:stop. The empty new Solr indexes are stored in ./myfaves/solr/development. Build Solr indexes from relational database Now we are ready to trigger a full index of the data in the relational database into Solr. acts_as_solr provides a very convenient rake task for this with a variety of parameters that you can learn about by running rake -D solr:reindex. We'll specify to work with a batch size of 1500 artists at a time: >>rake solr:start>>% rake solr:reindex BATCH=1500(in /examples/8/myfaves)Clearing index for Artist...Rebuilding index for Artist...Optimizing... This drastic simplification of configuration in the Artist model object is because we are using a Solr schema that is designed to leverage the Convention over Configuration ideas of Rails. Some of the conventions that are established by acts_as_solr and met by Solr are: Primary key field for model object in Solr is always called pk_i. Type field that stores the disambiguating class name of the model object is called type_s. Heavy use of the dynamic field support in Solr. The data type of ActiveRecord model objects is based on the database column type. Therefore, when acts_as_solr indexes a model object, it sends a document to Solr with the various suffixes to leverage the dynamic column creation. In /examples/8/myfaves/vendor/plugins/acts_as_solr/solr/solr/conf/ schema.xml, the only fields defined outside of the management fields are dynamic fields: <dynamicField name="*_t" type="text" indexed="true" stored="false"/> The default search field is called text. And all of the fields ending in _t are copied into the text search field. Fields to facet on are named _facet and copied into the text search field as well. The document that gets sent to Solr for our Artist records creates the dynamic fields name_t, group_type_s and release_date_d, for a text, string, and date field respectively. You can see the list of dynamic fields generated through the schema browser at http://localhost:8982/solr/admin/schema.jsp. Now we are ready to perform some searches. acts_as_solr adds some new methods such as find_by_solr() that lets us find ActiveRecord model objects by sending a query to Solr. Here we find the group Smash Mouth by searching for matches to the word smashing: % ./script/consoleLoading development environment (Rails 2.3.2)>> artists = Artist.find_by_solr("smashing")=> #<ActsAsSolr::SearchResults:0x224889c @solr_data={:total=>9, :docs=>[#<Artist id: 364, name: "Smash Mouth"...>> artists.docs.first=> #<Artist id: 364, name: "Smash Mouth", group_type: 1, release_date: "2006-09-19 04:00:00", created_at: "2009-04-17 18:02:37", updated_at: "2009-04-17 18:02:37"> Let's also verify that acts_as_solr is managing the full lifecycle of our objects. Assuming Susan Boyle isn't yet entered as an artist, let's go ahead and create her:  >> Artist.find_by_solr("Susan Boyle")=> #<ActsAsSolr::SearchResults:0x26ee298 @solr_data={:total=>0, :docs=>[]}>>> susan = Artist.create(:name => "Susan Boyle", :group_type => 1, :release_date => Date.new)=> #<Artist id: 548200, name: "Susan Boyle", group_type: 1, release_date: "-4712-01-01 05:00:00", created_at: "2009-04-21 13:11:09", updated_at: "2009-04-21 13:11:09"> Check the log output from your Solr running on port 8982, and you should also have seen an update query triggered by the insert of the new Susan Boyle record: INFO: [] webapp=/solr path=/update params={} status=0 QTime=24 Now, if we delete Susan's record from our database: >> susan.destroy=> #<Artist id: 548200, name: "Susan Boyle", group_type: 1, release_date: "-4712-01-01 05:00:00", created_at: "2009-04-21 13:11:09", updated_at: "2009-04-21 13:11:09">=> #<Artist id: 548200, name: "Susan Boyle", group_type: 1, release_date: "-4712-01-01 05:00:00", created_at: "2009-04-21 13:11:09", updated_at: "2009-04-21 13:11:09"> Then there should be another corresponding update issued to Solr to remove the document: INFO: [] webapp=/solr path=/update params={} status=0 QTime=57 You can verify this by doing a search for Susan Boyle directly, which should return no rows at http://localhost:8982/solr/select/?q=Susan+Boyle.

(For more resources on Oracle, see here.) The Interactive Reporting document: The BQY When working with Interactive Reporting, it is hard to escape the term BQY. BQY or BrioQuery, is the extension given to all Interactive Reporting document files. Developers create BQY files using the Workspace, Interactive Reporting Web Client, or Interactive Reporting Studio—a developer tool used to create and manage BQY documents outside of the EPM Workspace. The EPM Workspace The EPM Workspace is similar to a portal, where all Oracle Hyperion applications, reports, and other files can be accessed and integrated using a shared security model. The Workspace is accessible through the web browser and contains a filesystem and other gadgets including personal pages and content subscription. Interactive Reporting is one of the many products that integrate with the Workspace, providing users a central location to save, share, and publish content. Navigating the EPM Workspace To navigate the Workspace, a user account must be created and provisioned with the necessary privileges to the Workspace and the Interactive Reporting components. After the user account is created, users can access the Workspace using a web browser. Each environment may be configured differently and have different login methods and start pages configured. However, this article provides examples based on the default product configuration. The following screenshot shows the default login page for the EPM Workspace in version 11. Once the user enters the assigned username and password, the default home page appears. Other configurations may be configured to use external authentication methods, where the user will bypass the initial login screen and start at the default start page for their configuration. The default home page shown in the following screenshot is new to the Workspace in version 11. The new home page feature allows users to add Quick Links, browse recently opened documents, and view custom created Workspace pages. (Move the mouse over the image to enlarge.) If the desired content is not listed on the main home page, the Explorer can be accessed by clicking on the Explore image on the toolbar at the top of the page, allowing users to browse for content in the Workspace filesystem similar to Windows Explorer. The Explore window, shown in the following screenshot, opens to a page with two frames showing a folder structure on the left for navigating the file structure and the contents of the current folder on the right for managing and executing items. The main parent folder in the file system is called the Root folder and other files and folders can be added under the Root folder as desired. If there is a need to return to the previous page, the user can click on the HomePage tab at the bottom-left of the page. As additional items are opened in the Workspace, additional tabs are created at the bottom of the screen. The user can navigate through the different items opened by using the tabs across the bottom of the Workspace window. If desired, these tabs can be closed by right-clicking on the tab and selecting Close. After navigating to the desired folder, the user can open the documents of interest. Files from different applications are designated with two unique identifiers in the Explore window. The first identifier is the image that is shown to the left of the name, and the second identifier is the object Type. The documents shown in the previous screenshot are Interactive Reporting documents and can be opened using the HTML viewer or the Interactive Reporting Web Client. Selecting the HTML option will render the document in a new tab, while opening the document in the Interactive Reporting Web Client will open the document in a new browser window. Installing the Interactive Reporting Web Client The Interactive Reporting Web Client software must be installed to open documents in the Web Client. This installation is a plug-in to the browser, where the browser will activate the Web Client software when an Interactive Reporting file is initiated. The installation will automatically execute upon opening the Interactive Reporting document in a browser without the Web Client installed, or the installation can be manually executed by accessing the Tools | Install | Interactive Reporting Web Client item as shown in the following screenshot: Once the installation is initiated, a window appears with the ability to customize the installation by checking/unchecking options. The default installation will install all of the components of the tool and is recommended: The installation will commence after clicking on the Next button on the configuration menu and will continue through the completion of the installation, signified by the following window: Opening documents in the Workspace Interactive Reporting documents are opened by double-clicking on the document in the Workspace or by highlighting and right-clicking the document, highlighting Open As, and selecting either HTML or Interactive Reporting Web Client from the menu as shown in the following screenshot. When the document is double-clicked, the default configuration method for opening the document is invoked by Interactive Reporting. Initially the software is configured to use the HTML viewer as the default, but the default preference can easily be changed by modifying the Default Open Format of the document in the Interactive Reporting preferences of the Workspace. The main Preferences window is opened by accessing the File menu and selecting the Preferences menu item, as shown in the following screenshot. Once the Preferences window is open, the Default Open Format is found under the Interactive Reporting tab on the left menu of the window. To change the default format from HTML to the Interactive Reporting Web Client, click on the drop-down arrow, select the Interactive Reporting Web Client item, and then click on the OK button on the Preferences window. In addition to the file open format, other preferences can be modified in this window to address changing formats for date, time, and currency. Opening documents from the local machine Interactive Reporting documents can be saved and opened from the local machine by opening the document using the web browser with Web Client installed. To open the document from the local machine, highlight and right-click on the Interactive Reporting file and select Open With from the menu that appears. If the web browser of choice is not listed, select Choose Program from the list. Browse the window, select the web browser with the plug-in installed, and check the checkbox at the bottom to Always use the selected program to open this kind of file in order to always open the Interactive Reporting document in the selected web browser. Then select OK in the window to open the Interactive Reporting document with the web browser. The web browser will open and the Web Client will load the document into the viewing window. If offline mode is not turned on, the document will open a window to authenticate with the Workspace. If no connection can be established with the Workspace, only the data sections will be visible when the document is opened. If the connection can be established and the file saved to the desktop still exists in the Workspace, then the document will load with proper permissions to the file and the document can be processed as if it was opened from the Workspace. If the file is not located in the Workspace, then the file can be imported by the user if the user has import permissions. Instructions for importing are found in the importing section of this article. The Web Client interface Understanding the Web Client interface is crucial to being proficient in the product. The different sections of the software contain a variety of different options, but the location of where to find and utilize these options is the same across the tool. Knowledge of the interface and how to leverage the features of each section is key to unlock the full potential of the product. The sections of an Interactive Reporting document are the different objects in the software used to aid in querying, analyzing, or displaying information. There are seven types of unique sections. The specifics of each section are as follows: The Query section is the main section used to setup and execute a query from a relational or multi-dimensional database. Each Query section is accompanied by a Results section where the data returned from the Query is displayed and can be manipulated. The Table section is similar to the Results section and is used to manipulate and split a dataset into different subsets for analysis. The Pivot section is specific to a Results or Table section, and is used to graphically display data in pivot table format—similar to Microsoft Excel Pivots. The Chart section is also specific to a Results or Table section and is used to display data in a chart. The Report section provides the ability to present pivots, charts, and tables of data in a well formatted document. Dashboards are used to create custom interfaces or interactive displays of key metrics. The following screenshot displays the Interactive Reporting Web Client window open to the Query section. The arrows shown in the screenshot highlight each of the different features and toolbars of the product. These different features and toolbars can be toggled on and off using the View menu: The Section Catalogue The Section Catalogue, displayed on the left of the previous screenshot, contains two windows for navigating and editing sections. The Sections window displays the different sections in the document, and the Elements window is used to add content to a section. Both windows are used commonly when building documents and performing analysis. Menus The Interactive Reporting Web Client Menus are similar to a typical menu structure seen in most Windows-based applications. Interactive Reporting contains a standard set of menus and each section also contains menus specific to a section. The following menu items are consistent between all product sections: The File menu provides the features for managing the document, including the ability to save documents both to the local drive and to the Workspace, the ability to import external data, and the ability to export and print content. The Edit menu contains the general options for managing sections. These features include the standard copy and paste options, but also include the ability to delete, rename, and duplicate sections. The View menu contains the features for managing the different windows and views of the document, including showing/hiding windows and displaying query-specific information. The Insert menu is used to add a new section into the document. The Format menu is used to format the display of sections, including font, color, size, type, and other common formatting options. The Tools menu provides the ability to execute queries and manage default and program options. The Help menu contains the help contents, links, and information about the product version. These menu items are shown in the following screenshot: Toolbars The Interactive Reporting Web Client contains three standard toolbars used to manage views, content, and formatting. The toolbars are turned on and off through the View menu. To show or hide a toolbar from the viewing area, go to View Menu | Toolbars, and then click on the toolbar name to show or hide it. A checkbox next to the toolbar signifies the toolbar is shown in the viewing area. The following is a description of each of the three toolbars: The Standard toolbar contains shortcuts to the common standard features of the tool including saving, printing, inserting, and query processing. The Formatting toolbar contains controls to manage fonts, backgrounds, and number formats. The Section toolbar only applies to the Dashboard, Report, and Chart sections, and is used to modify and control object layouts and chart types. Section Title Bar The Section Title Bar has two different purposes. The bar contains a navigation dropdown on the left of the bar, and it contains section-specific controls on the right-side of the bar which is used to toggle options on and off. These options are specific to each section and are used to build queries, add content to a section, or to sort content. When these options are toggled on, the options will be displayed at the top or bottom of the main content window. Status Bar The Status Bar is shown at the bottom of the Web Client interface and contains information on a specific section. The information provided in the Status Bar includes the number of rows returned from a query, the number of rows shown in a results set, the number of rows and columns in a pivot table, the number of report pages, and the zoom settings on the dashboard.

(For more resources on Drupal, see here.) Not everything that is available in Drupal's Configuration section is discussed in this article. Some settings are very straightforward and really don't warrant more than perhaps a brief mention. Before we start It is sensible to make note of a few important things before getting our hands dirty. Make it second nature to check how the changes made to the settings affect the site. Quite often settings you modify, or features you add, will not behave precisely as expected and without ensuring that you use a prudent approach to making changes, you can sometimes end up with a bit of a mess. Changes to the site's structure (for example, adding new modules) can affect what is and isn't available for configuration so be aware that it may be necessary to revisit this section. Click on Configuration in the toolbar menu. You should see something like the following screenshot: A quick point to mention is that we aren't giving over much space to the final option—Regional and Language. This is because the settings here are very basic and should give you no trouble at all. There is also an online exercise available to help you with date types and formats if you are interested in customizing these. Let's begin! Site information This page contains a mixed bag of settings, some of which are pretty self-explanatory, while others will require us to think quite carefully about what we need to do. To start with, we are presented with a few text boxes that control things like the name of the site and the site slogan. Nothing too earth shattering, although I should point out that different themes implement these settings differently, while some don't implement them at all. For example, adding a slogan in the default Garland theme prints it after the site name as shown in the following screenshot: Whereas, the Stark theme places the slogan beneath the site name: Let's assume that there is a page of content that should be displayed by default—before anyone views any of the other content. For example, if you wanted to display some sort of promotional information or an introduction page, you could tell Drupal to display that using this setting. Remember that you have to create the content for this post first, and then determine its path before you tell Drupal to use it. For example, we could reference a specific node with its node ID, but equally, a site's blogs could be displayed if you substitute node/x (in node/ID format) for the blog. Once you are looking at the content intended for the front page, take note of the relative URL path and simply enter that into the text box provided. Recall that the relative URL path is that part of the page's address that comes after the standard domain, which is shared by the whole site. For example, setting node/2 works because Drupal maps this relative path to http://localhost/drupal/node/2 The first part of this address, http://localhost/drupal/ is the base URL, and everything after that is the relative URL path. Sometimes, the front page is a slightly more complex beast and it is likely that you will want to consider Panels to create a unique front page. In this case, Panels settings can override this setting to make a specific panel page as the front page. The following settings allow you to broadly deal with the problem of two common site errors that may crop up during a site's normal course of operation—from the perspective of a site visitor. In particular, you may wish to create a couple of customized error pages that will be displayed to the users in the event of a "page not found" or "access denied" problem. Remember that there are already pretty concise pages, which are supplied by default. However, if you wish to make any changes, then the process for creating an error page is exactly the same as creating any other normal page. Let's make a change very quickly. Click on Add new content in the Shortcuts menu and select Basic page. Add whatever content you want for, say the Page not found! error: Don't worry about the host of options available on this page—we will talk about all of this later on. For now, simply click on the Save button and make note of the URL of the page when it is displayed. Then head back to the Site information page, add this URL to the Default 404 (not found) page dialog, and then click on the Save configuration button: If you navigate to a page that doesn't exist, for example, node/3333, you should receive the new error message as follows: In this example, we asked Drupal to find a node that does not exist yet and so it displayed the Page not found! error message. Since Drupal can also provide content that is private or available to only certain users, it also needs the access denied error to explain to the would-be users that they do not have sufficient permissions to view the requested page. This is not the same as not finding a page, of course, but you can create your own access denied page in exactly the same way. Finally, you will need to specify how often cron should run in the Automatically run cron drop-down at the bottom of the Site information page. Cronjobs are automated tasks (of any type—they could be search indexing, feed aggregation, and so on) that should run at specified intervals. Drupal uses them to keep itself up-to-date and ensure optimal operation. Drupal uses web page requests to initiate new cron runs once the specified interval has elapsed. If your website does not get visited regularly, cron itself cannot run regularly. Running cron every few hours is reasonable for the vast majority of sites. Setting it to run too quickly can create a huge load on the server because each time the cron is run, all sorts of scripts are updating data, performing tasks, and consuming server resources. By the same token, run cron too infrequently and your site's content can become outdated, or worse, important module, theme, and core updates can go unnoticed, among other things. Actions and triggers Quite often, it happens that for specific events, it is useful to have Drupal automatically perform a specified task or action. An action, in the Drupal sense, is one of a number of tasks that the system can perform, and these usually relate to e-mailing people or acting upon user accounts or content. There are a number of simple actions that are available as well as a few more advanced ones that can be set up by anyone with sufficient permissions. To configure actions, navigate to Actions in SYSTEM under the Configuration menu in the toolbar: Default simple actions cannot be modified, so we will ignore these for the moment and focus on creating a new, advanced action. Set up a new Send e-mail action by selecting it from the drop-down list and click on the Create button, as shown in the preceding screenshot. This brings up the following page that can be set according to how this specific action will be used: It should be clear that the intention of this e-mail is to notify the staff/administration of any new site members. The Label field is important in this respect because this is how you will distinguish this action from the other ones that you may create in the future. Make the description as accurate, meaningful, and concise as possible to avoid any potential confusion. Also notice that there are several placeholder variables that can be inserted into the Recipient, Subject, and Message fields. In this instance, one has been used to inform the e-mail recipient of the new user name, as part of the message. A click on the Save button adds this new action to the list where it can be modified or deleted, accordingly: So far so good—we have set the action, but this in itself does absolutely nothing. An action cannot do anything unless there is a specific system event that can be triggered to set it off. These system events are, perspicaciously enough, called triggers and Drupal can look for any number of triggers, and perform the actions that are associated with it—this is how actions and triggers work together. Triggers are not part of the topic of Drupal configuration. However, we will discuss them here for completeness, since actions and triggers are integrally linked. Triggers are not enabled by default, so head on over to the Modules section and enable the Triggers module. With the module enabled, there will now be a new Triggers link from the Actions page. Clicking on this brings up the following page: Triggers are divided into five different categories, each providing a range of triggers to which actions can be attached. Assigning a trigger is basically selecting an action to apply from the drop-down list of the relevant trigger and clicking on the Assign button. To continue with our example, select the USER tab from the top of the Triggers overlay and, in the TRIGGER: AFTER CREATING A NEW USER ACCOUNT box, select the newly defined action, as shown in the following screenshot: Click on the Assign button, and the newly assigned action will show up in the relevant trigger box: In the same way, a large number of actions can be automated depending on the system event (or trigger) that fires. To test this out, log off and register a new account—you will find that the New User Alert e-mail is dutifully sent out once the account has been registered (assuming your web server is able to send e-mail).

Introduction BPEL4People has been developed to provide extensive support for human interactions in BPEL processes and to standardize the human interactions. Originally, the BPEL4People specification was defined by IBM and SAP. Other companies, such as Oracle, Active Endpoints, and Adobe have also joined. Today, this specification has being advanced within the OASIS BPEL4People Technical Committee. The BPEL4People specification contains two parts: BPEL4People version 1.0, which introduces BPEL extensions to address human interactions in BPEL Web Services Human Task (WS-HumanTask) version 1.0 introduces the definition of human tasks BPEL4People is defined in a way that it is layered on top of the BPEL language. We will now have a brief look at the WS-HumanTask and then at the BPEL4People. Brief look at WS-HumanTask The WS-HumanTask specification introduces Human Tasks to BPEL. Human Tasks are services, implemented by humans. A Human Task has two interfaces. One interface exposes the service offered by the task, like a translation service or an approval service. The second interface allows people to deal with tasks, for example to query for human tasks waiting for them, and to work on these tasks. This is very similar to human tasks in WebSphere, with two main differences—WS-HumanTask standardizes tasks among different vendors, and WS-HumanTask introduces new activities for specifying the properties of human tasks. In WebSphere, we had to use the Integration Developer GUI instead. WS-HumanTask makes a distinction between Human Tasks and notifications. Notifications are a special type of Human Task that allows the sending of information about noteworthy business events to users. Notifications are always delivered one-way. There is no response from notifications expected. Overall structure The overall structure of the human interactions definition is as follows: <?xml version="1.0" encoding="UTF-8"?><htd:humanInteractions targetNamespace="anyURI" expressionLanguage="anyURI"? queryLanguage="anyURI"?> <htd:extensions>? <htd:extension namespace="anyURI" mustUnderstand="yes|no"/>+ </htd:extensions> <htd:import namespace="anyURI"? location="anyURI"? importType="anyURI" />* <htd:logicalPeopleGroups>? <htd:logicalPeopleGroup name="NCName" reference="QName"?>+ <htd:parameter name="NCName" type="QName" />* </htd:logicalPeopleGroup></htd:logicalPeopleGroups><htd:tasks>? <htd:task name="NCName">+ ... </htd:task> </htd:tasks><htd:notifications>? <htd:notification name="NCName">+ ... </htd:notification> </htd:notifications></htd:humanInteractions> Human Tasks The most important is the definition of the Human Task. The definition includes the following: Interface Priority People assignments Delegation Presentation elements Outcome Search priorities Renderings Deadlines (start and competition deadlines) The WS-HumanTask specification foresees the following syntax to define a human task: <htd:task name="NCName"> <htd:interface portType="QName" operation="NCName" responsePortType="QName"? responseOperation="NCName"?/> <htd:priority expressionLanguage="anyURI"?>? integer-expression </htd:priority> <htd:peopleAssignments> ... </htd:peopleAssignments> <htd:delegation potentialDelegatees= "anybody|nobody|potentialOwners|other"/>? <htd:from>? ... </htd:from> </htd:delegation> <htd:presentationElements> ... </htd:presentationElements> <htd:outcome part="NCName" queryLanguage="anyURI">? queryContent </htd:outcome> <htd:searchBy expressionLanguage="anyURI"?>? expression </htd:searchBy> <htd:renderings>? <htd:rendering type="QName">+ ... </htd:rendering> </htd:renderings> <htd:deadlines>? <htd:startDeadline>* ... </htd:startDeadline> <htd:completionDeadline>* ... </htd:completionDeadline> </htd:deadlines> </htd:task> Escalations Within the deadlines, escalations can be defined. An example of defining an escalation is shown as follows: <htd:escalation name="highPrio"> <htd:condition> <![CDATA[ (htd:getInput("OrderRequest")/amount < 1000 && htd:getInput("OrderRequest")/prio <= 10) ]]> </htd:condition> <htd:notification name="ClaimApprovalOverdue"> <htd:interface portType="tns:ClaimsHandlingPT" operation="escalate" /> <htd:peopleAssignments> <htd:recipients> <htd:from logicalPeopleGroup="Manager"> <htd:argument name="region"> htd:getInput("OrderRequest")/region </htd:argument> </htd:from> </htd:recipients> </htd:peopleAssignments> <htd:presentationElements> <htd:name> Order approval overdue. </htd:name> </htd:presentationElements> </htd:notification> </htd:escalation> In a similar way, a reassignment could be done. Notifications Notifications are defined with the following: Interface Priority People assignments Presentation elements Renderings An example is shown as follows: <htd:notification name="NCName"> <htd:interface portType="QName" operation="NCName"/> <htd:priority expressionLanguage="anyURI"?>? integer-expression </htd:priority> <htd:peopleAssignments> <htd:recipients> ... </htd:recipients> <htd:businessAdministrators>? ... </htd:businessAdministrators> </htd:peopleAssignments> <htd:presentationElements> ... </htd:presentationElements> <htd:renderings>? ... </htd:renderings> </htd:notification> Programming interface The WS-HumanTask specification also defines the API for applications that are involved with the life cycle of a human task or a notification. It provides several types of operations, including: Participant operations, such as operation for claiming tasks, starting, stopping, suspending tasks, completing tasks, setting priority, delegating, and so on Simple query operations, such as getMyTasks and getMyTaskAbstracts Advanced query operation, which provides several possibilities for retrieving the tasks Administrative operations for nominating and activating tasks, and setting generic human roles The specification also defined XPath extension functions to retrieve Human Task properties. Now that we are familiar with WS-HumanTask, let us have a brief look at the BPEL4People specification. Brief look at BPEL4People BPEL4People is a BPEL extension, which adds several activities to the BPEL language. The most important extensions introduced in BPEL4People are people activities and people links. People activities are used to define human interactions. For each people activity, the BPEL server must create work items and distribute them to users eligible to execute them. People activities can have input and output variables and can specify deadlines. This is very similar to what we have seen in the WebSphere support for human tasks. To specify the implementation of people activities, BPEL4People introduces tasks. Tasks specify actions that users must perform. Tasks can have descriptions, priorities, deadlines, and other properties. Tasks can be represented in-line, or using WS-HumanTask. To associate people activities and the related tasks with users or groups of users, BPEL4People introduces people links. They associate users with one or more people activities. People links are usually associated with generic human roles, such as process initiator, process stakeholders, owners, and administrators. Overall structure The overall structure of BPEL4People extensions is as follows: <bpel:process ... > ... <bpel:extensions> <bpel:extension namespace="http://www.example.org/BPEL4People" mustUnderstand="yes"/> <bpel:extension namespace="http://www.example.org/WS-HT" mustUnderstand="yes"/> </bpel:extensions> <bpel:import importType="http://www.example.org/WS-HT" …/> <b4p:humanInteractions>? <htd:logicalPeopleGroups>? <htd:logicalPeopleGroup name="NCName">+ ... </htd:logicalPeopleGroup> </htd:logicalPeopleGroups> <htd:tasks>? <htd:task name="NCName">+ ... </htd:task> </htd:tasks> <htd:notifications>? <htd:notification name="NCName">+ ... </htd:notification> </htd:notifications> </b4p:humanInteractions> <b4p:peopleAssignments> ...</b4p:peopleAssignments> ...<bpel:extensionActivity> <b4p:peopleActivity name="NCName" ...> ... </b4p:peopleActivity> </bpel:extensionActivity> ...</bpel:process> Let us have a look at the new elements: The element <b4p:humanInteractions><b4p:/humanInteractions> contains declarations of elements from the WS-HumanTask namespace, such as <htd_logicalpeoplegroups></htd_logicalpeoplegroups>, <htd_tasks></htd_tasks>, and <htd_notifications></htd_notifications>. The element <htd_logicalpeoplegroup></htd_logicalpeoplegroup> specifies a logical people group used in an inline human task or a people activity. The <htd_task></htd_task> element is used to provide the definition of an inline human task. The <htd_notification></htd_notification> element is used to provide the definition of an inline notification. The element <b4p_peopleassignments></b4p_peopleassignments> is used to assign people to process-related generic human roles. The new activity <b4p_peopleactivity></b4p_peopleactivity> is used to model human interactions within BPEL processes. People assignments BPEL4People defines generic human roles. These roles define what a person or a group of people can do with the process instance. The specification defines three process-related generic human roles: Process initiator: Person that triggered the process instance Process stakeholders: People who can influence the progress of a process instance, for example, by adding ad-hoc attachments, forwarding a task, or simply observing the progress of the process instance Business administrators: People allowed to perform administrative actions on the business process instances The syntax of people assignments looks like this: <b4p:peopleAssignments> <b4p:processInitiator>? <htd:from ...> ... </htd:from> </b4p:processInitiator> <b4p:processStakeholders>? <htd:from ...> ... </htd:from> </b4p:processStakeholders> <b4p:businessAdministrators>? <htd:from ...> ... </htd:from> </b4p:businessAdministrators> </b4p:peopleAssignments> People activities People activities are used to integrate human interactions within BPEL processes. A people activity can be integrated with an inline Human Task or with a standalone Human Task. An inline task can be defined as part of a people activity. A standalone Human Task is defined separately and can be used several times. To specify Human Tasks, we use the WS-HumanTask specification. The overall syntax is as follows: <b4p:peopleActivity name="NCName" inputVariable="NCName"? outputVariable="NCName"? isSkipable="xsd:boolean"? standard-attributes> standard-elements ( <htd:task>...</htd:task> | <b4p:localTask>...</b4p:localTask> | <b4p:remoteTask>...</b4p:remoteTask> | <htd:notification>...</htd:notification> | <b4p:localNotification>...</b4p:localNotification> | <b4p:remoteNotification>...</b4p:remoteNotification> ) <b4p:scheduledActions>? ... </b4p:scheduledActions> <bpel:toParts>? <bpel:toPart part="NCName" fromVariable="BPELVariableName"/>+ </bpel:toParts> <bpel:fromPart part="NCName" toVariable="BPELVariableName"/>+ <bpel:fromPart>? </bpel:fromParts> <b4p:attachmentPropagation fromProcess="all|none" toProcess="all|newOnly|none"/>? </b4p:peopleActivity> Summary In this article, we have covered the BPEL4People and WS-HumanTask specifications. These specifications have standardized the approach to BPEL human interactions and made it portable through different SOA process servers. We have overviewed both specifications and have seen that there are no major conceptual differences between the current Oracle support and the approach taken in specifications. At the time of writing, it has not been clear how much support these specifications will get from SOA platform vendors. Further resources on this subject: Human Interactions in BPEL [Article] Business Processes with BPEL [Article] Web Services, SOA, and WS-BPEL Technologies [Article] SOA—Service Oriented Architecture [Article] Oracle Web Services Manager: Authentication and Authorization [Article]

(For more resources on BPEL, SOA and Oracle see here.) Human interactions in business processes The main objective of BPEL has been to standardize the process automation. BPEL business processes make use of services and externalize their functionality as services. BPEL processes are defined as a collection of activities through which services are invoked. BPEL does not make a distinction between services provided by applications and other interactions, such as human interactions, which are particularly important. Real-world business processes namely often integrate not only systems and services, but also humans. Human interactions in business processes can be very simple, such as approval of certain tasks or decisions, or complex, such as delegation, renewal, escalation, nomination, chained execution, and so on. Human interactions are not limited to approvals and can include data entries, process monitoring and management, process initiation, exception handling, and so on. Task approval is the simplest and probably the most common human interaction. In a business process for opening a new account, a human interaction might be required to decide whether the user is allowed to open the account. In a travel approval process, a human might approve the decision from which airline to buy the ticket (as shown in the following figure). If the situation is more complex, a business process might require several users to make approvals, either in sequence or in parallel. In sequential scenarios, the next user often wants to see the decision made by the previous user. Sometimes, particularly in parallel human interactions, users are not allowed to see the decisions taken by other users. This improves the decision potential. Sometimes one user does not even know which other users are involved, or whether any other users are involved at all. A common scenario for involving more than one user is workflow with escalation. Escalation is typically used in situations where an activity does not fulfill a time constraint. In such a case, a notification is sent to one or more users. Escalations can be chained, going first to the first-line employees and advancing to senior staff if the activity is not fulfilled. Sometimes it is difficult or impossible to define in advance which user should perform an interaction. In this case, a supervisor might manually nominate the task to other employees; the nomination can also be made by a group of users or by a decision-support system. In other scenarios, a business process may require a single user to perform several steps that can be defined in advance or during the execution of the process instance. Even more complex processes might require that one workflow is continued with another workflow. Human interactions are not limited to only approvals; they may also include data entries or process management issues, such as process initiation, suspension, and exception management. This is particularly true for long-running business processes, where, for example, user exception handling can prevent costly process termination and related compensation for those activities that have already been successfully completed. As a best practice for human workflows, it is usually not wise to associate human interactions directly to specific users; it is better to connect tasks to roles and then associate those roles with individual users. This gives business processes greater flexibility, allowing any user with a certain role to interact with the process and enabling changes to users and roles to be made dynamically. To achieve this, the process has to gain access to users and roles, stored in the enterprise directory, such as LDAP (Lightweight Directory Access Protocol). Workflow theory has defined several workflow patterns, which specify the abovedescribed scenarios in detail. Examples of workflow patterns include sequential workflow, parallel workflow, workflow with escalation, workflow with nomination, ad-hoc workflow, workflow continuation, and so on. Human Tasks in BPEL So far we have seen that human interaction in business processes can get quite complex. Although BPEL specification does not specifically cover human interactions, BPEL is appropriate for human workflows. BPEL business processes are defined as collections of activities that invoke services. BPEL does not make a distinction between services provided by applications and other interactions, such as human interactions. There are mainly two approaches to support human interactions in BPEL. The first approach is to use a human workflow service. Several vendors today have created workflow services that leverage the rich BPEL support for asynchronous services. In this fashion, people and manual tasks become just another asynchronous service from the perspective of the orchestrating process and the BPEL processes stay 100% standard. The other approach has been to standardize the human interactions and go beyond the service invocations. This approach resulted in the workflow specifications emerging around BPEL with the objective to standardize the explicit inclusion of human tasks in BPEL processes. The BPEL4People specification has emerged, which was originally put forth by IBM and SAP in July 2005. Other companies, such as Oracle, Active Endpoints, and Adobe joined later. Finally, this specification is now being advanced within the OASIS BPEL4People Technical Committee. The BPEL4People specification contains two parts: BPEL4People version 1.0, which introduces BPEL extensions to address human interactions in BPEL as a first-class citizen. It defines a new type of basic activity, which uses human tasks as an implementation, and allows specifying tasks local to a process or use tasks defined outside of the process definition. BPEL4People is based on the WS-HumanTask specification that it uses for the actual specification of human tasks. Web Services Human Task (WS-HumanTask) version 1.0 introduces the definition of human tasks, including their properties, behavior, and a set of operations used to manipulate human tasks. It also introduces a coordination protocol in order to control autonomy and lifecycle of service-enabled human tasks in an interoperable manner. The most important extensions introduced in BPEL4People are people activities and people links. People activity is a new BPEL activity used to define user interactions; in other words, tasks that a user has to perform. For each people activity, the BPEL server must create work items and distribute them to users eligible to execute them. People activities can have input and output variables and can specify deadlines. To specify the implementation of people activities, BPEL4People introduced tasks. Tasks specify actions that users must perform. Tasks can have descriptions, priorities, deadlines, and other properties. To represent tasks to users, we need a client application that provides a user interface and interacts with tasks. It can query available tasks, claim and revoke them, and complete or fail them. To associate people activities and the related tasks with users or groups of users, BPEL4People introduced people links. People links are somewhat similar to partner links; they associate users with one or more people activities. People links are usually associated with generic human roles, such as process initiator, process stakeholders, owners, and administrators. The actual users that are associated with people activities can be determined at design time, deployment time, or runtime. BPEL4People anticipates the use of directories such as LDAP to select users. However, it doesn't define the query language used to select users. Rather, it foresees the use of LDAP filters, SQL, XQuery, or other methods. BPEL4People proposes complex extensions to the BPEL specification. However, so far it is still quite high level and doesn't yet specify the exact syntax of the new activities mentioned above. Until the specification becomes more concrete, we don't expect vendors to implement the proposed extensions. But while BPEL4People is early in the standardization process, it shows a great deal of promise. The BPEL4People proposal raises an important question: Is it necessary to introduce such complex extensions to BPEL to cover user interactions? Some vendor solutions model user interactions as just another web service, with well-defined interfaces for both BPEL processes and client applications. This approach does not require any changes to BPEL. To become portable, it would only need an industry-wide agreement on the two interfaces. And, of course, both interfaces can be specified with WSDL, which gives developers great flexibility and lets them use practically any environment, language, or platform that supports Web Services. Clearly, a single standard approach has not yet been adopted for extending BPEL to include Human Tasks and workflow services. However, this does not mean that developers cannot use BPEL to develop business processes with user interactions. Human Task integration with BPEL To interleave user interactions with service invocations in BPEL processes we can use a workflow service, which interacts with BPEL using standard WSDL interfaces. This way, the BPEL process can assign user tasks and wait for responses by invoking the workflow service using the same syntax as for any other service. The BPEL process can also perform more complex operations such as updating, completing, renewing, routing, and escalating tasks. After the BPEL process has assigned tasks to users, users can act on the tasks by using the appropriate applications. The applications communicate with the workflow service by using WSDL interfaces or another API (such as Java) to acquire the list of tasks for selected users, render appropriate user interfaces, and return results to the workflow service, which forwards them to the BPEL process. User applications can also perform other tasks such as reassign, escalate, route, suspend, resume, and withdraw. Finally, the workflow service may allow other communication channels, such as e-mail and SMS, as shown in the following figure: Oracle Human Workflow concepts Oracle SOA Suite 11g provides the Human Workflow component, which enables including human interaction in BPEL processes in a relatively easy way. The Human Workflow component consists of different services that handle various aspects of human interaction with business process and expose their interfaces through WSDL; therefore, BPEL processes invoke them just like any other service. The following figure shows the overall architecture of the Oracle Workflow services: As we can see in the previous figure, the Workflow consists of the following services: Task Service exposes operations for task state management, such as operations to update a task, complete a task, escalate a task, reassign a task, and so on. When we add a human task to the BPEL process, the corresponding partner link for the Task Service is automatically created. Task Assignment Service provides functionality to route, escalate, reassign tasks, and more. Task Query Service enables retrieving the task list for a user based on a search criterion. Task Metadata Service enables retrieving the task metadata. Identity Service provides authentication and authorization of users and lookup of user properties and privileges. Notification Service enables sending of notifications to users using various channels (e-mail, voice message, IM, SMS, and so on). User Metadata Service manages metadata, related to workflow users, such as user work queues, preferences, and so on. Runtime Configuration Service provides functionality for managing metadata used in the task service runtime environment. Evidence Store Service supports management of digitally-signed workflow tasks. BPEL processes use the Task Service to assign tasks to users. More specifically, tasks can be assigned to: Users: Users are defined in an identity store configured with the SOA infrastructure. Groups: Groups contain individual users, which can claim a task and act upon it. Application roles: Used to logically group users and other roles. These roles are application specific and are not stored in the identity store. Assigning tasks to groups or roles is more flexible, as every user in a certain group (role) can review the task to complete it. Oracle SOA Suite 11g provides three methods for assigning users, groups, and application roles to tasks: Static assignment: Static users, groups, or application roles can be assigned at design time. Dynamic assignment: We can define an XPath expression to determine the task participant at runtime. Rule-based assignment: We can create a list of participants with complex expressions. Once the user has completed the task, the BPEL process receives a callback from the Task Service with the result of the user action. The BPEL process continues to execute. The Oracle Workflow component provides several possibilities regarding how users can review the tasks that have been assigned to them, and take the corresponding actions. The most straightforward approach is to use the Oracle BPM Worklist application. This application comes with Oracle SOA Suite 11g and allows users to review the tasks, to see the task details, and to select the decision to complete the task. If the Oracle BPM Worklist application is not appropriate, we can develop our own user interface in Java (using JSP, JSF, Swing, and so on) or almost any other environment that supports Web Services (such as .NET for example). In this respect, the Workflow service is very flexible and we can use a portal, such as Oracle Portal, a web application, or almost any other application to review the tasks. The third possibility is to use e-mail for task reviews. We use e-mails over the Notification service. Workflow patterns To simplify the development of workflows, Oracle SOA Suite 11g provides a library of workflow patterns (participant types). Workflow patterns define typical scenarios of human interactions with BPEL processes. The following participant types are supported: Single approver: Used when a participant maps to a user, group, or role. Parallel: Used if multiple users have to act in parallel (for example, if multiple users have to provide their opinion or vote). The percentage of required user responses can be specified. Serial: Used if multiple users have to act in a sequence. A management chain or a list of users can be specified. FYI (For Your Information): Used if a user only needs to be notified about a task, but a user response is not required. With these, we can realize various workflow patterns, such as: Simple workflow: Used if a single user action is required, such as confirmation, decision, and so on. A timeout can also be specified. Simple workflow has two extension patterns: Escalation: Provides the ability to escalate the task to another user or role if the original user does not complete the task in the specified amount of time. Renewal: Provides the ability to extend the timeout if the user does not complete the task in the specified time. Sequential workflow: Used if multiple users have to act in a sequence. A management chain or a list of users can be specified. Sequential workflow has one extension pattern: Escalation: Same functionality as above. Parallel workflow: Used if multiple users have to act in parallel (for example, if multiple users have to provide their opinion or vote). The percentage of required user responses can be specified. This pattern has an extension pattern: Final reviewer: Is used when the final review has to act after parallel users have provided feedback. Ad-hoc (dynamic) workflow: Used to assign the task to one user, who can then route the task to other user. The task is completed when the user does not route it forward. FYI workflow: Used if a user only needs to be notified about a task, but a user response is not required. Task continuation: Used to build complex workflow patterns as a chain of simple patterns (those described above).

Introduction In DNN, skinning is a term that refers to the process of customizing the look and feel of the DNN portal. One of the powerful features of DNN is that the functionality of the portal is separated from the presentation of the portal. This means we can change the appearance of the portal without affecting how the portal works. To create a skin in DNN we will work with three kinds of files: HTML, ASCX, and CSS. The HTML or ASCX file describes the layout of the page and the CSS file provides the styling. If you have worked with HTML and CSS before than you will be able to immediately get started. However, if you are familiar with ASCX (and as a DNN developer that is likely) you can achieve the same results faster than HTML. In the recipes, we will show primarily ASCX skinning with some brief examples of HTML skinning. Skin Objects Before we start looking at the recipes, we need a quick word about Skin Objects. Skin Objects are used in both HTML and ASCX skin files as placeholders for different kinds of dynamic functionality. In HTML skins, you place text tokens such as [CURRENTDATE] in your code and when the code is parsed by the skin engine it will insert the matching skin object. If you are working in ASCX, you register skin objects as controls that you place directly in your code. DNN offers many different skin objects such as CurrentDate, Logo, Login link, and others and we'll see many of these in action in the recipes of this article. Downloading and installing a skin Often the easiest way to start skinning is to download an existing skin package and see the different files used for skinning. In this recipe we will download an excellent skin created by Jon Henning from a site called CodePlex that demonstrates the most common skin objects and layouts. Another reason for starting with an existing skin is that it allows incremental development. We can start with a fully functional skin, deploy it to our DNN portal and then edit the source files right on the server. In this way the changes we make are immediately displayed and problems are easily spotted and fixed. However, as applying a skin can affect the entire site, it is best to create and test skins on a development DNN site before using them on a production site. Finally, it should also be noted that as a skin is really just another type of extension in DNN, you are already familiar with some of these steps. How to do it... Open your favorite web browser and go to the site http://codeendeavortemplate.codeplex.com/. Click on Downloads in the toolbar. Scroll down a little and click on the CodeEndeavors Template Skin link. When prompted with the License Agreement, click I Agree. The File download dialog will ask if you want to Open or Save. Click on Save and select a temporary folder to hold the ZIP file. That's all we need from the CodePlex site, so close the browser. To install the skin on the DNN site, begin by logging in as the SuperUser. Look at the Control Panel and make sure you're in Edit mode. Look under the Host menu and select Extensions. Scroll to the bottom and click on the link Install Extension Wizard. The wizard will prompt for the ZIP file (called the extension package). Click on the Browse button and select the file you just downloaded (for example CodeEndeavors.TemplateSkin.install.v01.01.07.00.zip). Click on Open then click on Next. The wizard will display the Extension information. Click on Next. The wizard will display the Release Notes. Click on Next. On the license page, check Accept License? and click on Next. Now the install script will run, creating the skin. At the end you should see the message "Installation successful". Click on Return. To make the skin active, select Skins under the Admin menu. (Move the mouse over the image to enlarge.) From the Skins drop-down lists, select CodeEndeavors.TemplateSkin. For this article, we will use the Index skin for our examples. Click on the Apply link under the index skin to make it active. To see the skin files, you can look in the root folder of the DNN instance under Portals_defaultSkinsCodeEndeavors.TemplateSkin. Here is a summary of the key files you are likely to see in a skin like this: File name Description animated.ascx An ASCX skin file. container.ascx An ASCX container file. index.html An HTML skin file. skin.css The stylesheet for the skin. container.css The stylesheet for the container. TemplateSkin.dnn The manifest file for the skin package. thumbnail_animated.jpg A preview image of the ASCX skin. thumbnail_container.jpg A preview image of the ASCX container. thumbnail_index.jpg A preview image of the HTML skin. license.txt The text of the license agreement. releasenotes.txt The text of the release notes. version.txt The version number. Images folder A folder holding the graphic images supporting a skin or container.