Implement Customer Master using Options-XML (Part 2)

How to operate customer master using basic function of Questetra BPM Suite (Part 2)

Hi, there.
The other day, in response to the requests,

“Can we manage customer master data by Questetra BPM Suite?”
“Want to use customer master data for various business!”

I wrote the blog post, Implement Customer Master using Options-XML (Part 1). As described in the summary of that, this time,

Implement Customer Master using Options-XML (Part 1)
In the example of Options-XML, data items is set easy-to-use for billing process. Then, by setting various attributes, I think you will be able to use customer information in many kinds of business processes.

However, it is assumed to receive some opinions like

It is bothersome to change Options-XML manually. I seem to make wrong operations.
I want to check detailed information at the time of drafting.

Of course, we have a solution for responding such opinions. (2016-06-09)

I would like to introduce a solution for responding our customers’ request.

== What to Realize ==

I think that “Manage customer master data” indicates the following two things.

  • (Correctly) Add customer master.
  • (Correctly and easily) Modify customer master.

Add customer master” means “Not adding if registered customer master exists“.
Modify customer master” means “Modify customer master so as not to make mistakes” “Modify customer master based on existing data“.


In addition to these requests, it seems that it requires meeting the general business rule for adding/modifying master, “Registering addition/modification after approval and confirmation”.

== Implementation Example ==

I have created a process model including “what we want to realize”.
(There exists an adopted example.)

<Implementation Example : Process Model >
fig1: process diagram

This example has several devising points.

  • (Point 0)Check/Select the existing customer master before “Addition”/”Modification”.
  • (Point 1)Avoid causing mistakes by separating the “Addition”/”Modification” application into different tasks.
  • (Point 2)Suggest the re-application if the applied data has already been included in the existing customer master.
  • (Point 3)Immediately reflect to the customer master after the approval of “Addition”/”Modification”

Let me give explanations to the each of these points.

0. Check/Select the existing customer master before “Addition”/”Modification”

In the input screen of new customer registration, we think so as not to make input errors as much as possible.

<Implementation Example : New customer registration screen>

fig2: new customer registration

Since the select type process data item for checking if the customer name has already been registered or not is prepared, the applicant can confirm it.
When applying registration modification of existing customers, I think you would like to input data using the existing customer master.


< Implementation Example : Customer master modification processing animation>

fig3: Customer master modification gif animation


Setting options-XML (Shared File) of customer master as shown below. In conjunction with the selection of the change target customer in JavaScript, it is realized by expanding the contents of options-XML ID (value).

< Implementation Example : Options-XML of Customer Master >

fig4: Options-XML preview


< Implementation Example : JavaScript for Expanding Options-XML to Each Data Item>
<button type="button" id="getMasterData">Customer Master Data Expansion</button>

<script type="text/javascript">
    // Selected data ID (Customer name)
    var selectedId = jQuery('input[name="data[0].dummy"]').val();
    // Selected data label (comma delimited various information)
    var slectedLabel = jQuery('input[name="data[0].selects"]').val();
    var customerDatas = slectedLabel.split(";");  // Delimited by delimiter ";"
    // Customer Name
    // Email address of sales representative
    // Closing Date Type
    // Billing Amount
    // Customer Representative Name
    // Customer ID

1. Avoid Causing Mistakes by Separating the “Addition”/”Modification” Application into Different Tasks

By separating start event and first task into “Addition” task and “Modification” task, you can select the starting task intuitively. Though realizing it in a single task processing screen is possible, in some cases, separating the screen explicitly will be more understandable.

< Implementation Example : Separate “Addition”/”Modification” of Customer Master in New Start >
fig5: Separate addition/modification into different tasks

2. Suggest the Re-application if the Data Has Already been Included in the Existing Customer Master

Since the same customer name cannot be registered to the customer master, you will be able to use correct customer master safely. Immediately after “Addition” application of customer master, Script task will search the contents of existing customer master data. The suggestion of re-application is realized by setting the search results to select type process data item used for the split points.

< Implementation Example : Script for Searching the “Addition” Customer Name from Customer Master>
var customerName = data.get("11");  // Input customer name
                                    // Get customer master
var optionsList = itemDao.findAll("CustomerMaster", true); 

var selects = new java.util.ArrayList();
selects.add("false");                // Customer name does not exist
retVal.put("14", selects);
for (i=0; i < optionsList.size(); i++){
	if (optionsList.get(i).getDisplay() == customerName){
		selects.add("true"); // Customer name exists
		retVal.put("14", selects);

3. Immediately Reflect to the Customer Master after the Approval of “Addition”/”Modification”

Using Script task, we can generate the options-XML data for reflecting immediately after the approval. Based on the existing customer master, we only modify target lines of the master data with the “Modification” case, while we add target customer information to the master data with the “Addition” case.

<Implementation Example : Script for Generating Customer Master (Options-XML data)>
var customerName = data.get("11");  // Input customer name
var optionsList = itemDao.findAll("CustomerMaster", true); // Options-XML"Customer Master"
// Customer master with no modification+Customer master generation (in the case of modification)
var optionsNum = optionsList.size();
var value_id_list = "";
var display_label_list = "";
for (i=0; i < optionsNum; i++){
	display_label_list += optionsList.get(i).getDisplay() + "\n";  // Make customer master (Label)
	if (optionsList.get(i).getDisplay() == customerName){  // If customer to be modifed
		value_id_list += data.get("1") + ";" + data.get("2") + ";" + data.get("5") + ";" + data.get("3") + ";" + data.get("13") + "\n"; // To-be modified customer master (value)
		value_id_list += optionsList.get(i).getValue() + "\n"; // Customer master with no modification (value)
// Generate Customer Master (in the case of being added)
var selects = data.get("6");  // Get modification type
var select = selects.get(0);
if (select.getValue() == "insert"){
	value_id_list += data.get("1") + ";" + data.get("2") + ";" + data.get("5") + ";" + data.get("3") + ";" + data.get("13") + "\n";  // Add customer master (value)
	display_label_list += customerName + "\n";  // Add customer master (label)
retVal.put("8", value_id_list);       // Options-XML value
retVal.put("9", display_label_list);  // Options-XML label

== Afterword ==

I think that this implementation example has approximately met "What you want to realize".
When focusing on detailed parts, however, it still includes inadequate points.

From the viewpoint of business,

  • You can wrongly register new data with different order of Co., Ltd. (Japanese style notation: 株式会社XXX or XXX株式会社)
  • Customer ID can be wrongly changed.


From the viewpoint of system,

  • there is a possibility that it will fail to reflect applications of Modification/Addition when crowded.


Options-XML uses reversal method for updating data, and does not have exclusion control. There is a possibility that it processes modification on the basis of the old customer master at the time of multiple application and approval processings. (Since the modification timing is placed in the end of process, it rarely occur.)


However, for the problems mentioned above, you can clear them by the approach from operational aspect and further system contrivance. What is important is whether master configuration and handling of master on bussiness is clearly determined or not.


If you "Want to realize easily!", but "Want to handle with appropriate business rule!", please feel free to consult us. We think that we can have suggestions that can solve your worries.

Please try to challenge by all means. If you want to take a look at the process model of implementation, please contact us.

About Masato Furukubo

Questetra, Inc. Sales Department
View all posts by Masato Furukubo

Prev article - 55. Improvement Tips How to Evaluate Questetra (Step 1)
Next article - 55. Improvement Tips How to Evaluate Questetra (Step 2)
Another article - Masato Furukubo How to Substitute Approval Step with “Email Reply”