Parse Excel File

Many a times, we need to import data from excel into PRPC data structures. There are quite a few ways to do so, here I am describing an OOTB internal activity to import data from Excel (XSLX) into PRPC clipboard.

As a pre requisite we need a template excel file uploaded as Rule-File-Binary.  Later this template file is used to interpret the uploaded spread sheets values and map into appropriate clipboard structures. Always have the first row as heading, and second row should have following syntax

{.PageListName().PropertyName input}

Next write an activity, to get the file location of the uploaded excel file (use FileUpload control to upload the excel sheet), and then call OOTB internal activity named MSOParseExcelFile. This activity takes two mandatory properties, first is the location and name of the uploaded excel file, second is the name of the template file.

With this MSOParseExcelFile would map the contents of the excel file in to appropriate clip board structures.

Here is a scenario illustrating the same

Scenario: Upload Employee Details (Name, ID, Manager, Age) from an excel file

Step1: Create Template File and upload it is Rule-File-Binary

Step 2: Write an activity to call MSOParseExcelFile

Param Supplied:

FSFFileName : Name and Location of the uploaded excel file.

TemplateRFB: Name of the uploaded binary file, it should follow <Directory name>!<Rule Name>!<extension>

Step 3: Run the activity to check results

Hope the above article is covers most of the required stuff. Please leave a comment with your practical experiences on how useful this article was and also any thing needs further explanations. 

Feedback's are welcomed in the form of comments.

Vamshi

Sub Case Vs SubFlow

Often during a design discussion, we hear questions / discussions like, why do we need a sub case for this task, cant this be done by a sub flow? Whatever a sub case can do, sub flow can do the same, let’s not complicate by having sub cases. Contrary, we also hear, design a sub case, we can extend it later if required. All of these questions / discussions are valid, but not directed or supported. Here is a small article, describing when to use which Design Paradigm, which would help us make above design discussions directed and supportive with data points

Given the capabilities for each, there are many ways to compare pros and cons of each. However, the scenario or requirements should be detrimental  of the design paradigm.

- Sub Flows, in this discussion represent Sub Process / Spin Offs / Split for Each / Split for Join

- “Task” has to be read either as Sub Flow or Sub case depending on the context

Dependency Management: Is the a requirement to Start off the “Task”, when certain conditions are met. Example: StartLoanEvaluation “Task” needs to be performed only after Customer submitting required Proofs for Source of Income.

Sub Flows: Not Achievable.

Sub cases: Achievable.  

Data Propagation:  

·         Is the requirement to not show /save unwanted data to the “Task” or to show / save as much data as required to perform the “Task”.  Example: To perform an Assessment of a loan, Assement officer should know about Loan Details / Income and expenditure details, but not required to know about applicant’s personal details.

Sub Flows: Not Achievable.

Sub cases: Achievable.  Using Data Propagation, we can select the data properties to be copied into sub cases.

·         Is the requirement not to have stale data while performing the “Task”

Sub Flows: Achievable.

Sub cases: Not Achievable.  We need to write custom code to fetch data from parent to child case.

Specialization:

·         Is the requirement to Specialize flow rules

Sub Flows: Achievable.

Sub cases: Not Achievable.  

·         Is the requirement to Specialize Class rules

Sub Flows: Not Achievable.

Sub cases: Achievable.  

Storage:

·         Is the requirement to store the details of the “Task” in separate table. Example: Store all Underwritten claims to a different table

Sub Flows: Not Achievable.

Sub cases: Achievable.

Security:

·         Is the requirement to have different secured strategies for the “Task”.

Sub Flows: Not Achievable.

Sub cases: Achievable.

Reporting:

·         Is the requirement to have fine grain report for the “Task”

Sub Flows: Not Achievable.

Sub cases: Achievable.

Policy Override:

·         Is the requirement to suspend only the “Task”, when certain conditions are met

Sub Flows: Not Achievable.

Sub cases: Achievable.

·         Is the requirement to suspend not only  the “Task” but also the origination flow, when certain conditions are met

Sub Flows: Achievable.

Sub cases: Not Achievable.

If we can have each box ticked off and then a simple math would help us decide which one should our design have, Sub Case or Sub Flows.

Hope the above article is covers most of the required stuff. Please leave a comment with your practical experiences on how useful this article was and also any thing needs further explanations. 

Feedback's are welcomed in the form of comments.

Vamshi