]> git.evergreen-ils.org Git - working/Evergreen.git/blob - docs/reports/reporter_add_data_source.txt
199314a572db79f3ec752e634296fd98cdcea923
[working/Evergreen.git] / docs / reports / reporter_add_data_source.txt
1 Adding Data Sources to Reporter\r
2 -------------------------------\r
3 \r
4 indexterm:[reports, adding data sources]\r
5 \r
6 You can further customize your Evergreen reporting environment by adding \r
7 additional data sources.\r
8 \r
9 The Evergreen reporter module does not build and execute SQL queries directly, \r
10 but instead uses a data abstraction layer called *Fieldmapper* to mediate queries \r
11 on the Evergreen database.Fieldmapper is also used by other core Evergreen DAO \r
12 services, including cstore and permacrud. The configuration file _fm_IDL.xml_ \r
13 contains the mapping between _Fieldmapper_ class definitions and the database. \r
14 The _fm_IDL.xml_ file is located in the _/openils/conf_ directory.\r
15 \r
16 indexterm:[fm_IDL.xml]\r
17 \r
18 There are 3 basic steps to adding a new data source. Each step will be discussed \r
19 in more detail in the\r
20 \r
21 . Create a PostgreSQL query, view, or table that will provide the data for your \r
22 data source.\r
23 . Add a new class to _fm_IDL.xml_ for your data source.\r
24 . Restart the affected services to see the new data source in Reporter.\r
25 \r
26 There are two possbile sources for new data sources:\r
27 \r
28 indexterm:[PostgreSQL]\r
29 \r
30 indexterm:[SQL]\r
31 \r
32 * An SQL query built directly into the class definition in _fm_IDL.xml_. You can \r
33 use this method if you are only going to access this data source through the \r
34 Evergreen reporter and/or cstore code that you write.\r
35 * A new table or view in the Evergreen PostgresSQL database on which a class \r
36 definition in _fm_IDL.xml_. You can use this method if you want to be able to \r
37 access this data source through directly through SQL or using other reporting tool.\r
38 \r
39 Create a PostgreSQL query, view, or table for your data source\r
40 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\r
41 \r
42 indexterm:[PostgreSQL]\r
43 \r
44 You need to decide whether you will create your data source as a query, a view, \r
45 or a table.\r
46 \r
47 . Create a query if you are planning to access this data source only through the \r
48 Evergreen reporter and/or cstore code that you write. You will use this query to \r
49 create an IDL only view.\r
50 . Create a view if you are planning to access this data source through other \r
51 methods in addition to the Evergreen reporter, or if you may need to do \r
52 performance tuning to optimize your query.\r
53 . You may also need to use an additional table as part of your data source if \r
54 you have additional data that's not included in the base Evergreen, or if you \r
55 need to use a table to store the results of a query for performance reasons.\r
56 \r
57 To develop and test queries, views, and tables, you will need\r
58 \r
59 * Access to the Evergree PostgreSQL database at the command line. This is \r
60 normally the psql application. You \r
61 can access the Postgres documentation at the \r
62 http://http://www.postgresql.org/docs/[Official Postgres documentation] for \r
63 more information about PostgreSQL.\r
64 * Knowledge of the Evergreen database structure for the data that you want to \r
65 access. You can find this information by looking at the Evergreen schema\r
66 http://docs.evergreen-ils.org/2.2/schema/[Evergreen schema] \r
67 \r
68 indexterm:[database schema]\r
69 \r
70 If the views that you are creating are purely local in usage and are not intended \r
71 for contribution to the core Evergreen code, create the Views and Tables in the \r
72 extend_reporter schema. This schema is intended to be used for local \r
73 customizations and will not be modified during upgrades to the Evergreen system.\r
74 \r
75 You should make that you have an appropriate version control pocess for the SQL \r
76 used to create you data sources.\r
77 \r
78 Here's an example of a view created to incorporate some locally defined user \r
79 statistical categories:\r
80 \r
81 .example view for reports\r
82 ----------\r
83 create view extend_reporter.patronstats as\r
84 select u.id, \r
85 grp.name as "ptype",\r
86 rl.stat_cat_entry as "reg_lib",\r
87 gr.stat_cat_entry as "gender",\r
88 ag.stat_cat_entry as "age_group",\r
89 EXTRACT(YEAR FROM age(u.dob)) as "age",\r
90 hl.id as "home_lib",\r
91 u.create_date,\r
92 u.expire_date,\r
93 ms_balance_owed\r
94 from actor.usr u\r
95 join permission.grp_tree grp \r
96         on (u.profile = grp.id and (grp.parent = 2 or grp.name = 'patron')) \r
97 join actor.org_unit hl on (u.home_ou = hl.id)\r
98 left join money.open_usr_summary ms \r
99         on (ms.usr = u.id) \r
100 left join actor.stat_cat_entry_usr_map rl \r
101         on (u.id = rl.target_usr and rl.stat_cat = 4) \r
102 left join actor.stat_cat_entry_usr_map bt \r
103         on (u.id = bt.target_usr and bt.stat_cat = 3) \r
104 left join actor.stat_cat_entry_usr_map gr \r
105         on (u.id = gr.target_usr and gr.stat_cat = 2) \r
106 left join actor.stat_cat_entry_usr_map gr \r
107         on (u.id = gr.target_usr and gr.stat_cat = 2) \r
108 left join actor.stat_cat_entry_usr_map ag \r
109         on (u.id = ag.target_usr and ag.stat_cat = 1) \r
110 where u.active = 't' and u.deleted <> 't';\r
111 -----------\r
112 \r
113 Add a new class to fm_IDL.xml for your data source\r
114 --------------------------------------------------\r
115 \r
116 Once you have your data source, the next step is to add that data source as a \r
117 new class in _fm_IDL.xml_.\r
118 \r
119 indexterm:[fm_IDL.xml]\r
120 \r
121 You will need to add the following attributes for the class definition\r
122 \r
123 * *id*. You should follow a consistent naming convention for your class names \r
124 that won't create conflicts in the future with any standard classes added in \r
125 future upgrades. Evergreen normally names each class with the first letter of \r
126 each word in the schema and table names. You may want to add a local prefix or \r
127 suffix to your local class names.\r
128 * *controller=”open-ils.cstore”*\r
129 * *oils_obj:fieldmapper=”extend_reporter::long_name_of_view”*\r
130 * *oils_persist.readonly=”true”*\r
131 * *reporter:core=”true”* (if you want this to show up as a “core” reporting source)\r
132 * *reporter:label*. This is the name that will appear on the data source list in \r
133 the Evergreen reporter.\r
134 * *oils_persist:source_definition*. If this is an IDL-only view, add the SQL query \r
135 here. You don't need this attribute if your class is based on a PostgreSQL view \r
136 or table.\r
137 * *oils_persist:tablename="schemaname.viewname or tablename"* If this class is \r
138 based on a PostgreSQL view or table, add the table name here. You don't need \r
139 this attribute is your class is an IDL-only view.\r
140 \r
141 For each column in the view or query output, add field element and set the \r
142 following attributes. The fields should be wrapped with _<field> </field>_\r
143 \r
144 * *reporter:label*. This is the name that appears in the Evergreen reporter.\r
145 * *name*. This should match the column name in the view or query output.\r
146 * *reporter:datatype* (which can be id, bool, money, org_unit, int, number, \r
147 interval, float, text, timestamp, or link)\r
148 \r
149 For each linking field, add a link element with the following attributes. The \r
150 elements should be wrapped with _<link> </link>_\r
151 * *field* (should match field.name)\r
152 * *reltype* (“has_a”, “might_have”, or “has_many”)\r
153 * *map* (“”)\r
154 * *key* (name of the linking field in the foreign table)\r
155 * *class* (ID of the IDL class of the table that is to be linked to)\r
156 \r
157 The following example is a class definition for the example view that was created \r
158 in the previous section.\r
159 \r
160 .example class definition for reports\r
161 ----------\r
162 <class id="erpstats" controller="open-ils.reporter-store" \r
163 oils_obj:fieldmapper="extend_reporter::patronstats" \r
164 oils_persist:tablename="extend_reporter.patronstats" oils_persist:readonly="true" \r
165 reporter:label="Patron Statistics" reporter:core="true">\r
166   <fields oils_persist:primary="id">\r
167   <field reporter:label="Patron ID" name="id" reporter:datatype="link" />\r
168   <field reporter:label="Patron Type" name="ptype" reporter:datatype="text" />\r
169   <field reporter:label="Reg Lib" name="reg_lib" reporter:datatype="text" />\r
170   <field reporter:label="Boro/Twp" name="boro_twp" reporter:datatype="text" />\r
171   <field reporter:label="Gender" name="gender" reporter:datatype="text" />\r
172   <field reporter:label="Age Group" name="age_group" reporter:datatype="text" />\r
173   <field reporter:label="Age" name="age" reporter:datatype="int" />\r
174   <field reporter:label="Home Lib ID" name="home_lib_id" \r
175         reporter:datatype="link" />\r
176   <field reporter:label="Home Lib Code" name="home_lib_code" \r
177         reporter:datatype="text" />\r
178   <field reporter:label="Home Lib" name="home_lib" reporter:datatype="text" />\r
179   <field reporter:label="Create Date" name="create_date" \r
180         reporter:datatype="timestamp" />\r
181   <field reporter:label="Expire Date" name="expire_date" \r
182         reporter:datatype="timestamp" />\r
183   <field reporter:label="Balance Owed" name="balance_owed" \r
184         reporter:datatype="money" />\r
185 </fields>\r
186 <links>\r
187   <link field="id" reltype="has_a" key="id" map="" class="au"/>\r
188   <link field="home_lib_id" reltype="has_a" key="id" map="" class="aou"/>\r
189 </links>\r
190 </class>\r
191 ---------\r
192 \r
193 NOTE: _fm_IDL.xml_ is used by other core Evergreen DAO services, including cstore \r
194 and permacrud. So changes to this file can affect the entire Evergreen \r
195 application, not just reporter. After making changes fm_IDL.xml, it is a good \r
196 idea to ensure that it is valid XML by using a utility such as *xmllint* – a \r
197 syntax error can render much of Evergreen nonfunctional. Set up a good change \r
198 control system for any changes to fm_IDL.xml. You will need to keep a separate \r
199 copy of you local class definitions so that you can reapply the changes to \r
200 _fm_IDL.xml_ after Evergreen upgrades.\r
201 \r
202 Restart the affected services to see the new data source in the reporter\r
203 ------------------------------------------------------------------------\r
204 \r
205 The following steps are needed to for Evergreen to recognize the changes to \r
206 _fm_IDL.xml_\r
207 \r
208 . Copy the updated _fm_IDL.xml_ Update _/openils/conf/fm_IDL.xml_ to \r
209 _/openils/var/web/reports/fm_IDL.xml_\r
210 +\r
211 -------------\r
212 cp _/openils/conf/fm_IDL.xml /openils/var/web/reports/fm_IDL.xml\r
213 -------------\r
214 +\r
215 . Run Autogen to to update the Javascript versions of the fieldmapper definitions.\r
216 +\r
217 -------------\r
218 /openils/bin/autogen.sh\r
219 -------------\r
220 +    \r
221 . Restart C services\r
222 +\r
223 -------------\r
224 osrf_ctl.sh -l -a restart_c\r
225 -------------\r
226 +\r
227 . Restart the Evergreen reporter. You may need to modify this command depending \r
228 on your system configuration and pid path\r
229 +\r
230 ------------\r
231 opensrf-perl.pl -l -action restart -service open-ils.reporter \\r
232 -config /openils/conf/opensrf_core.xml -pid-dir /openils/var/run\r
233 ------------\r
234 +\r
235 . Restart the Evergreen application or _use Admin --> For Developers --> Clear \r
236 Cache_\r
237 \r
238 \r
239 \r