So here’s the scenario: I am building an update-able dashboard to allow users to release jobs from said dashboard. The dashboard itself is just a clone of the production planner workbench but with one of the back-end queries changed to be an update-able BAQ.
From within the BAQ designer > Analyze sheet, the BAQ works as expected. I am able to select a record, click “Release” and run the update. Then logic fires to firm the job if it isn’t already firm and update the job number if the job was originally unfirm. This all works as expected. However when I attempt to release a job from the dashboard itself, only the “released” field updates in the database. “Firm” remains unchanged as does the job number.
I’ve made sure to verify that the dashboard is pointing to the uBAQ I’m testing from and I’ve re-deployed the dashboard, and verified the menu item in menu maintenance is pointing to the correct dashboard. Will BAQ update logic still run when attached to an update-able dashboard?
In my experience, yes. However, things are rarely this simple. I don’t have a solution for your post, but here are a few things to try:
Go to your BPM. Add a new BASE processing to the update method. Add a blank empty custom code element with just a comment in it. (I can’t explain this one, I do it to avoid issues with BPMs and Dashboards.)
Verify that needed fields are marked as updatable in the BAQ Update General Properties.
In the dashboard, make sure the Updatable flag is turned on for the query.
In the dashboard, verify the Prompt check box is checked for fields you want to update.
If you used custom actions, make sure to go to the Updatability tab of the Dashboard Grid Properties, then add the custom action to the list.
Update flag is turned on and prompt check box is enabled for both “Released” and "Firm:
I am not using any custom actions.
Unfortunately no change in behavior. Just to be safe, I redeployed the dashboard, created a new menu item in menu maintenance, and pointed said menu item to the new deployed dashboard dll.
What does your update processing tab look like? If you aren’t using custom actions, then you probably don’t need to use BMP directives. In the BAQ, look at the Update > Update Processing tab. Whats that screen look like? You must have it setup right if it works in the BAQ.
Redeploying should be enough. You don’t have to recreate the menu item every time. Not that it hurts anything, just delete your old menu items.
What about your dashboard. Do you have any customizations applied? What, if any code did you add?
Honestly, I am not sure what to do about your original question, but I am happy to help you figure it out. I am sure someone out there can help with this. There are some big brains here! @josecgomez, @dhewi
I do and that is a fantastic thought. Unfortunately, I’m seeing the same behavior in the dashboard without any customization applied.
But in case it becomes relevant - the customization is really simple. On this dashboard there are 3 tabs which show All Jobs, Jobs with shortages, and jobs with full availability:
I’ve added three buttons which are visible in the above screenshot. These buttons just let a user check all visible jobs in a specific one of these tabs: “Release All” button marks each job displayed in the “All Jobs” tab as “Released”, “Release Shortage Jobs” does the same for the “Shortage Jobs” tab and so on.
The code behind to accomplish this is attached below:
public class Script
{
// ** Wizard Insert Location - Do Not Remove 'Begin/End Wizard Added Module Level Variables' Comments! **
// Begin Wizard Added Module Level Variables **
// End Wizard Added Module Level Variables **
// Add Custom Module Level Variables Here **
//public List<string> jobList = new List<string>();
public void InitializeCustomCode()
{
// ** Wizard Insert Location - Do not delete 'Begin/End Wizard Added Variable Initialization' lines **
// Begin Wizard Added Variable Initialization
// End Wizard Added Variable Initialization
// Begin Wizard Added Custom Method Call
this.epiButtonReleaseAll.Click += new System.EventHandler(this.epiButtonReleaseAll_Click);
this.epiButtonReleaseFull.Click += new System.EventHandler(this.epiButtonReleaseFull_Click);
this.epiButtonReleaseShortage.Click += new System.EventHandler(this.epiButtonReleaseShortage_Click);
// End Wizard Added Custom Method Calls
}
public void DestroyCustomCode()
{
// ** Wizard Insert Location - Do not delete 'Begin/End Wizard Added Object Disposal' lines **
// Begin Wizard Added Object Disposal
this.epiButtonReleaseAll.Click -= new System.EventHandler(this.epiButtonReleaseAll_Click);
this.epiButtonReleaseFull.Click -= new System.EventHandler(this.epiButtonReleaseFull_Click);
this.epiButtonReleaseShortage.Click -= new System.EventHandler(this.epiButtonReleaseShortage_Click);
// End Wizard Added Object Disposal
// Begin Custom Code Disposal
// End Custom Code Disposal
}
private void epiButtonReleaseAll_Click(object sender, System.EventArgs args)
{
// ** Place Event Handling Code Here **
if (MessageBox.Show("Are you sure you want to release ALL JOBS?", "Confirm", MessageBoxButtons.YesNo, MessageBoxIcon.Question) == DialogResult.Yes)
{
EpiDataView dv = (EpiDataView)(oTrans.EpiDataViews["V_UD_uProductionPlannerJobs_2_1View3"]);
DataView datView = dv.dataView;
foreach(DataRowView rowView in datView)
{
rowView.Row["JobHead_JobReleased"] = true;
}
}
}
private void epiButtonReleaseFull_Click(object sender, System.EventArgs args)
{
// ** Place Event Handling Code Here **
if (MessageBox.Show("Are you sure you want to release all visible jobs with FULL AVAILABILITY?", "Confirm", MessageBoxButtons.YesNo, MessageBoxIcon.Question) == DialogResult.Yes)
{
EpiDataView dv = (EpiDataView)(oTrans.EpiDataViews["V_UD_uProductionPlannerJobs_2_1View1"]); // V_UD_uProductionPlannerJobs_2_1View3 = ALL JOBS
DataView datView = dv.dataView;
foreach(DataRowView rowView in datView)
{
rowView.Row["JobHead_JobReleased"] = true;
}
}
}
private void epiButtonReleaseShortage_Click(object sender, System.EventArgs args)
{
// ** Place Event Handling Code Here **
if (MessageBox.Show("Are you sure you want to release all SHORTAGE JOBS?", "Confirm", MessageBoxButtons.YesNo, MessageBoxIcon.Question) == DialogResult.Yes)
{
EpiDataView dv = (EpiDataView)(oTrans.EpiDataViews["V_UD_uProductionPlannerJobs_2_1View2"]); // V_UD_uProductionPlannerJobs_2_1View1 = Full only
DataView datView = dv.dataView;
foreach(DataRowView rowView in datView)
{
rowView.Row["JobHead_JobReleased"] = true;
}
}
}
}
And Nate, really appreciate you taking time out of your day to help me man.
I’m not in the same bracket as Jose, nowhere close.
I saw the original question but couldn’t think of any obvious answer. All I can offer is that if the BAQ is working as expected, the problem can’t be there. I think we would need to know more about this deployed dashboard because something is wrong with that, and these days we tend to build our functionality into customizations rather than the dashboards themselves so I probably don’t have the right experience to help much.
What would be interesting is to compare a trace from the update process as triggered from the BAQ designer with one from the update in the dashboard. That way you can at least start to see if the same things are going on in both.
A trace could be a big help here. I looked a bit closer and it seems like the logic you use to check the check boxes is not he same as when you manually check the box then update the record. If you run the trace, you might see that when you click a checkbox and then update in the BAQ, the trace might show a few methods being triggered beyond just the Update method. If this is the case, then in your button logic, you may have to check firm and change job num for each line. But here we are getting into duplicating the efforts of well crafted BO methods.
This seems like it should be doable through a simple update BAQ, but the reality may be a bit more complex under the hood. Look into tracing. And if you haven’t use Jose’s tracing tool to help decipher the huge trace files:
Gentlemen! First off, thank you both for your advice. This dashboard now appears to be working (I still need to put it through more rigorous testing, but so far so good).
@NateS - your comment in particular got me thinking:
If this is the case, then in your button logic, you may have to check firm and change job num for each line. But here we are getting into duplicating the efforts of well crafted BO methods.
I won’t bore you with all the details, but I ended up adding a BeforeFieldChange event to the Results_Column displayed in the dashboard:
