The Power of CAS: Part III
A solid user interface is crucial to every software tool. If the user interface, or UI, is not esthetically pleasing, or user friendly, the audience won’t enjoy the software as much and the quality of the product will be viewed as subpar. The Accenture CAS system not only has a very rich and complex programming structure in the background, but it also contains a very sophisticated UI as well. If domains, entities, basic data objects, and views are the foundation of the house that is Accenture CAS, the User Interface forms the roof. This entry will discuss four major UI types as well as the tools used in conjunction with them. The first UI Type we will discuss is the Tab Page. Tab Pages are viewed in almost every user interface in the Accenture CAS system. Each tab page is comprised mainly of two types of structures. The first is a group and the second is a grid. The group is used to display or enter data for an individual row; grids are primarily used to display multiple rows of data. Groups save and load data from one table’s row in the database. This can be obtained by using either a cdo or a view. The use of a view can be more complex because by their nature, views usually return more than one row. The view must have conditions that result in a result of one row if they are to be effectively used in conjunction with groups. Grids are meant to display one or more rows of information. Views become very important in accomplishing this task. By creating a grid based off a view, all of the results of the view will be displayed in the grid. The second User Interface Type we will discuss is a detail. Details are essentially containers holding a group of tabs that displays in the application. Details allow the user to navigate and view several tab pages and save data as needed. Without this container, tab pages could not be viewed. This gives the user an interface that is familiar to internet browsers. Notice that this customer detail has several tabs that can be traversed through. What makes details impressive is that the developer can set what users can view and edit tabs. This is made possible by edit and access rights. These edit and access rights or EA rights will set editing and visibility based on the users roles conditions being met. EA rights are established by adding principles to a grid. The principles will fire off in the order they were added, resulting in various edit and access rights being set for various users. Details all have a reference to a User Interface group, or definition called a Detail Context that allows it to be opened. There are several ways to open the detail, but generally one of two scenarios occurs. The detail is either opened in the application menu, which looks strikingly similar to a start menu or by loading from an Overview. Overviews are the next User Interface Type we will discuss. Overviews give the user the ability to select a profile to search for specific data needed to either open a detail or select data while using a Wizard. At first site, an overview will look similar to a tab page with a grid positioned inside it, but it contains much more. Profiles are uesd to load up a specifici set of data for searching. Each Overview must contain at least one profile and will contain three main features: Searches, Quick Searches, and Sortings. By looking at the creation of a new customer we can see how these features work. Searches are used to narrow the result set of each profile by entering criteria such as Ids, Valid Dates, and Names. Notice in the screenshot above that there are three grayed out criteria entries in the general search box. These represent the quick search. This allows users to just type in what they are searching for as opposed to entering them into the search box of that particular criteria. Finally, the Quicksort is used to Order the searche’s result set. The final User Interface type we will talk about is a wizard. Wizards are used in conjunction with creating new records or data or when adding rows to existing data. This can be seen when users create Visits. A visit, or call is one of the more prominent features in Accenture CAS. It is a means for users to track store visits, phone calls, sickness and even vacation data. When the user creates a call, a wizard will be shown. Notice that the wizard gives the user a choice of what type of call they will make.It also has a link to an overview for choosing customers. Once data has been chosen and the user presses finish, the data will be transferred from the wizard to the new call. This is done by sending the data through and “operation call.” An Operation Call can be used in several situations. For example, when the “New Call” is pressed, the Operation Call for the wizard is executed, and it loads the wizard data. Once the wizard is complete, an operation call for creating the Call is executed and the data is sent from the wizard to the call. The Accenture CAS system uses Visual Studio and Silverlight to provide users with what resembles common system interfaces. CAS contains a rich and complex backend that gives developers the tools needed to provide clients with a system of tracking and storing data. Accenture CAS is built from the ground up with a solid foundation of objects with several ways to deeply customize the application, displaying the data through the top layer of the system, the User Interface. Together these elements provide the user and clients with a great tool that can help maximize their company’s full potential.
The Power of CAS: Part II
The intent of this blog entry is to further inform readers of the functionality of the Accenture CAS System. Accenture CAS is the leading integrated sales platform for the consumer goods industry, providing companies with the ability to streamline all of their day to day operations. The CAS system uses four main tools, namely the CAS modeler, SQL Server Management Studio, Visual Studio 2010, and the CAS Application which uses Microsoft Silverlight. Today, we will focus on the following foundational CAS Modeler objects: Entities, Domains, Basic Data Objects (cdos), and Views. It can be said that the most important objects in the CAS System are Domains and Toggles. Domains represent data types of each attribute in an Entity. They can be predefined or created by a developer in the Modeler. Domains can have customer names, but each Domain be based on one of six data types. The data types are: Blob, Date, Decimal, LongText, NonUnicode, and String. Domains determine the type of data entry required in the User Interface. If the data type is a Date the user will have to enter a valid date into the system. The same is true for the other data types. A Toggle is known as a special form of Domain, comprised of the StringData Type. Each Toggle contains codes, items, and labels that are used for data storage. What makes Toggles special is that they are prefilled with Labels for the user to choose from as data. Each Label corresponds with an Item. Once the value is saved, a Code that corresponds to the Item is sent to the database for storage . For example, if a user is being created, there is a State Toggle. This holds a string label for each state in the nation. The creator must choose a state, and once the tab page is saved, the code for the selected item will be saved to the database. The Accenture CAS System has the ability to track and store data by using Views and CAS BasicData Objects, or cdos. In order to do this, there must first be a “building block” upon which Views and cdos can use to read and write data. These corner stones of the Accenture CAS System are Entities. An Entity is an object in the Accenture CAS System that contains the definition of a table. This essentially means that entities provide a schema of tables in the database, giving cdos and Views the correct information when performing queries on the database. Every entity contains two important sections: Includes and Attributes. Includes are preexisting packets of core attributes that may be needed for the current entity. Every entity will contain at least one Include named SysEntityObject. This contains attributes vital to saving and updating the data represented by the entity. The most important of these attributes is the PKey, or Primary Key. This attribute works exactly like Primary Keys in database systems. Each row in the corresponding table will have a distinct PKey that helps maintain data integrity. Attributes represent columns of a table in the database, and are added manually to an entity. As stated previously, attributes must contain a domain type. When an attribute is added to an entity, a dropdown box will appear containing all domains in that module. If a developer adds attributes to an entity that will link it to another, they must select a Domain of type DomPKey. This special attribute addition creates a relationship in the system to the other entity. This is important for use in Views and cdos who compare two or more entities. Now that we have covered Domains and Entities, we will look at Views and CAS Basic Data Objects (cdos). Notice that Entities are required for both Views and cdos. The difference between the two is the number of entities used in retrieving and storing data. A View can be created using one or more entities, where as a cdo is based off of one entity. Views are essentially select statements using relationships between entities as the constraints. Generally speaking, when a developer creates a View these relationships already exist due to their corresponding PKeys having been added to the other entity. However, if the relationship does not exist, it can be created when the view is created. Each view has a “Starting Element” that represents the entity being primarily selected from, and if other entities are needed, they will be added to the view based on their relation with the first entity. This allows views to narrow the results to a smaller set that meets all required constraints. Once all entities have been added, attributes from the entities can be added to display in the return set. For example, the preexisting view, BpaMainRoleView, has a starting entity of BpaMain. It then adds other entites based on relationships with BpaMain. The figure below depicts the scenario and shows all of the constraints for the view. The developer of this view has also added attributes from the various entities to display in the result set from the SQL Query generated. Once the view is run, it will select all data from all of the entities where the constraints are met and return the data to the application. CAS Basic Data Objects differ from Views in that they are used to access data from one entity. There are two ways to create cdos in the Modeler. First and most importantly, each entity will have a cdo created at the same time it is. These cdos have a basic condition stating “PKey = ?”. This will return all rows from the table where the PKey supplied is equal to the PKey of the row. Cdos can also be created seperately from an entity, but they will still require an entity to interact with as well as a condition. More custom-specific cdos can be created in this manner. For example, if a developer needed to have all Call Visits that are scheduled for a date greater than the current date returned, a cdo could be created with a constraint: “ClbMain.DateFrom >= #Today#”. Just as a building is based on its foundation, Accenture CAS is based of of Domains, Entities, Basic Data Objects, and Views. Domains are essential for Entities that represent table definitions. Entities are crucial for View and Basic Data Objects. User Interfaces in Accenture CAS are dependent on cdos and Views. The Accenture CAS User Interface will be discussed in later entries. If there are any other topics you would like hear about CAS, just let us know!
The Power of CAS
Rural Sourcing uses several technologies to bring the best products to our clients. One of the most used technologies is the Accenture CAS System. Accenture CAS is the leading integrated sales platform for the consumer goods industry. It provides companies with the ability to streamline all of their day to day operations whether it be tracking inventory, managing customers, making payments, setting up promotions, or even keeping up with sales representative store visits. The CAS system uses four main tools, namely the CAS modeler, SQL Server Management Studio, Visual Studio 2010, and the CAS Application which uses Microsoft Silverlight. The CAS Modeler is a graphical interface that simplifies the majority of the creation process, enabling developers to create UI Elements such as Tabs, Grids, and Groups without having to write any code. It is broken into several modules each having a specific area or usage. The most prominent modules are Bpa, Clb, Prd, Prm, and Usr. The Bpa module focuses on Customers and Contact Partners. This will include stores and the contacts connected to the store. The Clb module is used primarily for Collaboration and Visits. When a sales representative travels to a Customer, or Store, this module will be accessed. The Prd module is used for Product creation and inventory, and the Prm module is used for Promotions of the products in stores. Finally, the Usr module is used to keep up with all User accounts and logins. Each module in the system will have its own set of CAS data types that are used to read and write from the database. The following image will give you a basic idea of how the system is set up for each module. The basis for the CAS system is an Entity. These are essentially the definition of a table in the data base. From the Entity a Basic Data Object is created. This cdo is used to access one table in the database. Views can also be created, allowing the developer access to multiple tables in the database. Both Basic Data Objects and Views will be used in conjunction with a Data Container which links the data to Overviews and Details. The Overviews and Details are the final step and are displayed in the application tab page. SQL Server Management Studio is used by the CAS System to store data, but it is also instrumental during development for accessing the database for testing purposes. It allows developers to see any new content they have added to the individual tables, or changes to values in the database. SQL can also be used in Stored Procedures and Server Processes. In these processes, a developer can access the database to select data from or update data from the database. Visual Studio 2010 is also a vital tool used by the CAS System. All of the development in the modeler is Save and Deployed into code. There are two types of code created by CAS. The first is, “core“ code, which for all intents is uneditable. The second type is “customizable” code. This type of code can have “Insertion Ranges” added to it. These ranges are the segments of code that can be customized. The CAS Application uses Microsoft Silverlight to display what has been developed using the modeler and Visual Studio 2010. Depending on what roles a user contains, they will be able to access different UI Elements of the Application. Through these Tab Pages, Grids, and Groups along with other User Interface tools, the user can view or update data as the tab pages direct. As developers at Rural Sourcing we work with several clients using this technology to create the best solution to their needs. We will delve into some of the individual CAS components in future blog updates.