Question

BIX - Limit the count of the cases to be included in XML extract

Hi,

We are implementing BIX with output format as "XML". The scheduler is planned to run once every night.

We have a concern that the XML size could be too large as we need to extract all the completed cases, which could be upto 80,000 as this a call center.

So how do I restrict the number of cases that can be included in one XML. So let us say if I want to limit only 500 cases per XML and generate multiple XMLs, is this configurable?

Thanks

Gowri

***Updated by moderator: Lochan to add Categories***

**Moderation Team has archived post**

This post has been archived for educational purposes. Contents and links will no longer be updated. If you have the same/similar question, please write a new post.

Comments

Keep up to date on this post and subscribe to comments

Pega
January 26, 2016 - 11:56pm

Hi Gowri,

Currently with XML extraction, there is no configuration to split the file into multiple chunks for a large extract. This would be an enhancement that the BIX product would need.

-Rajiv

January 27, 2016 - 1:43pm

Rajiv,

Thanks for your response.

The extract rule does not seem to accept any parameters. Is it possible to pass parameters to this extract rules? so we can include only the cases updated in specific time range.

If we can pass parameters to the extract rule, then I can have the looping logic in the agent activity to call the extract rule with the time range as parameters

Thanks

Gowri

Pega
January 28, 2016 - 12:25am
Response to GowriD25

Hi Gowri,

The extract rule was mainly designed to run using the BIX command line and that is our recommended way to extracting data. When running from the command line, there is no access to parameters and thus the extract rule has not been designed to accept the same.

In command line options, you can leverage the -u and -U options to limit the ranges of records that you need to extract in one run. Please refer to the BIX user guide for details on how to run in command line - https://pdn.pega.com/documents/bix-71-user-guide

-Rajiv

February 4, 2016 - 7:28pm
Response to nistr

Rajiv,

Thanks. We are using cloud, looks like we cannot control the batch size in cloud even with command line approach

Thanks

Gowri

Pega
February 5, 2016 - 4:11am
Response to GowriD25

Batch size in BIX is meant for the records written to the target table. Since for BIX on cloud, we don't allow for writing the extracted data to an external DB, this option is not supported.

February 5, 2016 - 8:02am
Response to nistr

You are right it is applicable for extracting to external DB.

So the only option is to split the file is -u and -U parameters.

I don't have much idea about writing shell scripts. But my logic should be to make this java call in a loop and pass the arguments(pxUpdateDateTime) that should be evaluated dynamically before the call,

If anyone has attempted this before, please share the code

Thanks

Gowri

Pega
February 5, 2016 - 9:26am
Response to GowriD25

You won't be able to use shell on the cloud. You will need to use the pxExtractDataWithArgs activity to do that - Please refer to BIX User Guide (section: Running a BIX extract in Designer Studio)

February 5, 2016 - 5:55pm
Response to nistr

Rajiv,

   To summarize, if you refer to my original post, I am trying to figure out if it is doable programmatically though not supported by PEGA OOTB features.

The only option to do this is using the shell scripts and cron job, so we can pass dynamic arguments to this java call.

But then the above cannot be done in Cloud? Is that right?

Thanks

Gowri

Pega
February 7, 2016 - 12:30pm
Response to GowriD25

You should reach out to your account executive / partner alliance to know if BIX can be supported for your version of Pega platform on Pega Cloud.

February 4, 2016 - 8:06pm

As you are talking about the call center, I hope you are using CPM framework. You can create extract rules for each type to segregate or else you can create extract rules based on the worktype.

Alternative options:

  • Write different extract rules with different filtering criteria