Question
WIPRO
IN
Last activity: 9 Mar 2023 8:35 EST
Why BIX??
Hi - I am getting huge data as a REST API request and data stored in a pega table under PEGADATA as a blob column except for few key properties exposed. Now I am getting lot of reporting requirements which involves properties under BLOB.
If I recommend BIX, Customer is dead against this idea as they want to have reports within PEGA itself and asking why PEGA could not meet the required reporting needs. Is it good to bisect the BLOB and store the data into different data types and do the required reporting OR should we say PEGA is not primarily a reporting tool and hence BIX is needed to support reporting? Why BIX and why not Reporting in pega by doing a proper data modelling? Is pega not fit for reporting?
Updated: 14 Feb 2023 21:24 EST
JPMorgan Chase
IN
@MOHANRAJS7274 What is the data size, what is the nature of reports and it's calculations ,do you archive and purge old data, on what amount of data is this report being generated, do you have additional database to handle reporting load on to reporting database
there are multiple questions to solve to nail down your question.
multiple columns to pull out in report is not a problem
filtering multiple column data and scanning multiple rows is what makes the difference. so solve all these to showcase client what is the fit. Pega supports reporting with in certain boundary. if your data falls with in that , very well you can do reporting using pega.
WIPRO
IN
Thanks very much for a detailed reply. I agree with your points.
We archive data older than 6 months and roughly 2k cases per day volume. Reports needs to be based on past 6 months in some cases and few of the performance reports are daily, weekly and monthly.
The challenge I have is that, I am receiving huge data from external sources each have their own payload request (REST API). If I commit to the business that we can do reporting in PEGA, any changes to the payload, we will keep adding/deleting columns. Is that advisable? tables keep growing with dedicated columns which can cause duplication with blob.
My understanding so far is that PEGA can do reporting but not actually a proper reporting tool unless we keep all the data in a separate reporting database which could be a overkill in my usecase since the number of users using those reports is very less.
JPMorgan Chase
IN
With the data you given 2k cases per day mean for 6 months data will be 360000 cases per 6 month. Pega can very well support for such data. you don't even need reporting database for such data.
Proper data modelling, indexing will do the needful.
Adding columns, deleting columns, altering you have do it - no other go.
WIPRO
IN
@SriHarsha Anikathank you very much. One small query. If the volume is 36000 per month, can export excel function in report definition work fine with it? I am hearing from my colleagues that export excel does not perform well if the result size crosses 50k. Kindly share if you have view on this.
JPMorgan Chase
IN
Hope so you will export the data matching your criteria not entire 36000 records. Pega will perform good. you need to worry about how the data is being retrieved it's joins, query conditions, indexing of the data, filter conditions how are they being passed to the report definition to get good performance.
WIPRO
IN
@SriHarsha Anika Thanks for the response and sorry for replying late. Max volume of reports currently around 20K. In 2 years time, this might double. Not really sure export excel works fine in future when volume grows. We are planning to keep the must have real-time reports only in PEGA and BIX extract remaining data to have reports outside.
Ford Motor Company
US
@MOHANRAJS7274 Pega Reporting behaves slightly different from BIX Reporting. BIX Reporting holds snapshot version of the data, while Pega reporting will be current state.
Lets say, there is a Case Created at 1 PM EST, this case has lets say 75 Columns out of which 50 exposed and 25 are not exposed from BLOB, and you have configured to run BIX at 10 PM EST, BIX Job Scheduler will take the snap shot of the case and take the case information for the fileds that you selected in the extract rule into the BIX Tables aka lets say for reporting need you need only 20 Columns, so for that Case [database row], you will be copying all those 20 Columns out of 75 into BIX DB.
& Let's a you get the update to the case following day, Case Status might change or data might change on that case, and as per BIX process, since this case has an update [ BIX will have a timestamp called pxExtractDateTime, this will be compared against pxUpdateDateTime in the case] it will copy the case information at that time aka following day at 10 PM ET, will extract and add as additional row into BOX table, where as the case behavior is, Update to the row, BIX behavior is Insert into the table.
So BIX helps you keep some sort of Historical Data until it meets the BIX extract requirements and also allows you to extract subset of data instead of entire table copy.
@MOHANRAJS7274 Pega Reporting behaves slightly different from BIX Reporting. BIX Reporting holds snapshot version of the data, while Pega reporting will be current state.
Lets say, there is a Case Created at 1 PM EST, this case has lets say 75 Columns out of which 50 exposed and 25 are not exposed from BLOB, and you have configured to run BIX at 10 PM EST, BIX Job Scheduler will take the snap shot of the case and take the case information for the fileds that you selected in the extract rule into the BIX Tables aka lets say for reporting need you need only 20 Columns, so for that Case [database row], you will be copying all those 20 Columns out of 75 into BIX DB.
& Let's a you get the update to the case following day, Case Status might change or data might change on that case, and as per BIX process, since this case has an update [ BIX will have a timestamp called pxExtractDateTime, this will be compared against pxUpdateDateTime in the case] it will copy the case information at that time aka following day at 10 PM ET, will extract and add as additional row into BOX table, where as the case behavior is, Update to the row, BIX behavior is Insert into the table.
So BIX helps you keep some sort of Historical Data until it meets the BIX extract requirements and also allows you to extract subset of data instead of entire table copy.
So even if you purge the data from Work table, you will have a smaller sized data that is available in BIX, more importantly in your organization if any downstream system needs this data, you have flexibility to give direct access. Giving direct access to Pega tables is not advisable.
BIX license normally comes with your standard licensing, however you have confirm with your account rep or CSM to ensure you are allowed to use the BIX Software. One other item to consider, BIX require additional infrastructure[ either additional Database or additional schema or a Shared/NaaS drive etc.,]
So, bottom line there are no of factors that determines wheather you have to choose BIX or Pega Internal Tables.
Updated: 15 Feb 2023 10:36 EST
WIPRO
IN
@SUMAN_GUMUDAVELLY Thanks very much for a detailed reply. I agree with your points.
In my specific case, we have few reports which has to be real-time like performance reports of users within the workgroup or case reports in different workqueues etc AND some reports can be based on snapshot data as you mentioned.
The challenge I have is that, I am receiving huge data from external sources each have their own payload request (REST API). If I commit to them that we can do reporting in PEGA, any changes to the payload, we will keep adding/deleting columns. Is that advisable? In future table can grow with more columns with duplication in individual columns and BLOB.
My understanding so far is that PEGA can do reporting but not actually a proper reporting tool unless we keep all the data in a separate reporting database which could be a overkill in my usecase since the number of users using those reports is very less.