Domain Controller Machine
Other Machine
Related Articles
1. In IIS 7.0, click the Sites node, then get the ID for AgilePoint site.
2. Click on the AgilePoint node under Sites, then click on Logging icon.
3. Get the value for Directory:
4. Navigate to the location and select the subfolder with AgilePoint site ID. The IIS log file(s) is under that folder.
In the Setup project of VS.NET, you can write a InstallerClass and attach that to the Custom Action of the Setup project to do some custom steps like checking certain services, copying special files etc.
To debug this InstallerClass, just insert below line of code at the location you wish to set the break point.
System.Diagnostics.Debugger.Break();
When running your installer, Windows Installer will understand that’s a user defined breakpoint and let you chose to debug the program. See screen shots below.
After that, you can just press F10 to step through your code.
1. In AgilePoint Server Manager, check what is the web site associate with Enterprise Manager. In this case, the web site is call AgilePoint. Take note of the value of virtual directory. In this case, it is EM4.
2. Go to IIS Manager, right click on ‘AgilePoint’ site > Manage Web Site > Advance Setting, check the value for Physical Path. In this case, it is C:\Program Files\AgilePoint. So, the physical path for Enterprise Manager virtual directory is C:\Program Files\AgilePoint\EM4
Use msi2xml. For example, the file you want to replace is Test.dll and your MSI is TestMSI.MSI.
This command extracts the MSI files:
Open OutputDir and modify the file.
The extracted file names are some random numbers with no file extension, e.g. _132667984196873216. To identify the file you want to replace, open the TestMSI.xml generated by above command, then search for Test.dll and find the matching random number file name.
You may replace the file using the same random number file name. Modify the file size in TestMSI.xml too.
To pack the files back to MSI:
xml2msi.exe -m TestMSI.xml
You need the -m to ignore the 'MD5 checksum test' that fails when an MSIs file(s) are modified.
From my observation, the file size of MSI reduces after running xml2msi, but all the contents are correct.
There are customers come to me that they are not able to upgrade their AgilePoint Integration for SharePoint.
On their Add\Remove Program, they have the entry for AgilePoint Integration for SharePoint with v5.0. But when they run the v5.0 Service Pack 1 (v5.0 SP1) or v5.0 Service Pack 2 (v5.0 SP2), the upgrade installer gives below error:
“Please install or upgrade to AgilePoint v5.0 before installing this upgrade.”
This is because, the customer first run the SharePoint Integration installer (the MSI file), which will add the entry to the Add\Remove Program. This gives an illusion that it seems SharePoint Integration has been installed correctly. After this, if the customer does not use the SharePointV2IntegrationSetup.exe to deploy the SharePoint solution files (.wsp files), but instead the customer choses to manually deploy the SharePoint solution files (.wsp) using standard SharePoint stsadm tool, then the upgrade installer of v5.0 SP1 or v5.0 SP2 will not be able to detect that the SharePoint Integration has been installed.
To solve this, I recommend the customer to use same approach when SharePoint Integration was first deployed, i.e. use the stsadm tool. The details of using the stsadm tool can be found at the AgilePoint Install Guide, but here is a quick look:
| To upgrade the SharePoint machine manually, right-click and extract the installer file to obtain the solution files (.wsp) files at Net20\SharePointv2\. Now upgrade the 4 solution files (Ascentn.SharePoint.SettingsList.wsp, Ascentn.SharePoint.WebParts.wsp, Ascentn.SharePoint.WFIntegration.wsp, Ascentn.SharePoint.ListForm.wsp) individually using the command line example below: stsadm -o upgradesolution -name Ascentn.SharePoint.SettingsList.wsp -filename Ascentn.SharePoint.SettingsList.wsp –immediate -allowgacdeployment After upgrading the solution files, run this command: stsadm -o copyappbincontent |
This situation can easily happened when the person first installed the SharePoint Integration left the company and did not left any documentation about what he had done. I strongly recommend you to keep the documentation and records for each upgrade you have performed, so that you can pass on the info to the person who will be doing the next upgrade.
There are API and Event available in AgilePoint Express Edition.
It is about human task. In the real scenario/real world, when the task is assigned to someone, it does not mean assignee will start to work on the assignment immediately. AgilePoint captures the date assigned and date completed, but it does not keep the timestamp that assignee actually starts to work on the task.
API
In this enhancement, AgilePoint provides a new API ActivateWorkItem(workItemID, bool activate, string clientData) so, application can make web service call of this function to mark user starts working on the work. In some case, it could be captured when user open the form or other ways, for example, a button on the form because user might want to check the form first and then decide to start working immediately. If user regret, application can call same web service call and activate=false, which will deactivate the work item. Behind scene, when work item gets activated, the table WF_MANUAL_WORKITEMS.ACTIVATED_DATE will be set for activation, otherwise it will be reset if it is deactivated. Beside web service API, service API is also available.
EVENT for AgileWork and AgileExtender
ActivateWorkItem call would fire an event of ‘ActivateWorkItem’, currently AgileWork and AgileExtender is able to capture the event and take certain action.
AgilePoint Setting List is used to stored all the configuration info for AgilePoint Integration for SharePoint. The access to this list shall be limited to SharePoint Administrators only.
There is a case where some end users accidentally activate this feature at their personal site, i.e. Mysite. This adds additional AgilePointSettingUrl entry in the SharePoint web.config, which messes up the configuration for SharePoint Integration.
Here is how you can hide AgilePoint Setting List Feature in MySite, so that the users do not accidently activate or deactivate it. You can add an extra attribute Hidden="TRUE" in the feature.xml file of AgilePoint Settings List Feature to hide the feature from your end users.
The default location of the feature.xml is:
C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\TEMPLATE\FEATURES\AgilePointSettingsListFeature\feature.xml
Here is the sample content of the feature.xml. Add the Hidden="TRUE" at the Feature node.
<?xml version="1.0" encoding="utf-8" ?>
<Feature Id="A379136F-8742-4f0c-9D5A-9310A4D2B80C"
Title="$Resources:Feature_Title"
Description="$Resources:Feature_Description"
ImageUrl="AgilePoint\AgilePoint_Feature_logo.jpg"
Version="12.0.0.0"
Scope="Site"
ReceiverAssembly="Ascentn.SharePoint.SettingsList, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=f1099b605f3ea558"
ReceiverClass="Ascentn.SharePoint.SettingsList.AgilePointSettingsFeatureReceiver"
xmlns="http://schemas.microsoft.com/sharepoint/"
Hidden="TRUE">
<ElementManifests>
<ElementManifest Location="ListTemplates\AgilePointSettingsElements.xml" />
</ElementManifests>
</Feature>
The issue:
This happened after converting a vhd from Virtual Server 2005 to Hyper-V.
Projects in Visual Studio.NET 2008 can be built. No error message. The devenv.exe process occupied almost 100% of the CPU and keep running forever.
The attamp to repair Visual Studio 2008 does not help, but instead below error is shown.
“The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2908.”
Here is another error encountered.
“The procedure entry point CorGetSvc could not be located in the dynamic link library mscoree.dll”
The solution:
Go to Add/Remove Program, repair .NET Framework 3.5 SP1.
There is one tricky step in configuring the Windows Service version of AgilePoint Server.
After installing the AgilePoint Server, you launch the AgilePoint Server Manager below to enter the configuration info.
Once you are done with entering all the info and click the ‘Update’ button, it might freeze for a while and finally display below error.
This means something is preventing the Server Manager Configuration tool to enter the WCF binding elements into the web.config of Enterprise Manager. To solve this, launch the Windows Service Client Utility Tool from below default location
C:\Program Files\AgilePoint\AgilePoint Server\SVCUtilityTool\AgilePointWindowsServiceClientUtilityTool.exe
For the ‘Service address’ textbox, enter the http URL of AgilePoint Server. This is the tricky part. The port number shall be used in this URL is the http port number of AgilePoint Server that you entered in the AgilePoint Server Manager UI (see picture above), not the port number for Enterprise Manager.
Note that for IIS version of AgilePoint Server, the AgilePoint Server and the Enterprise Manager have to be installed at the same port number. But for Windows Service version of AgilePoint Server, the http ports of AgilePoint Server and Enterprise Manager can be different.
For the ‘Target Config’ textbox, enter the location of web.config of Enterprise Manager. Since you select a site for Enterprise Manager at the AgilePoint Server Manager tool, you can check the location of the virtual directory of the site at IIS Manager.
Click the ‘Generate’ button after this. It might take a while to execute.
If you see this error:
“The config was not generated, please check the Service address”,
then just launch the Services console and make sure the credential you use to run the windows service is right (Right click the AgilePoint service in the Services Console > Property > Log On tab). You might need to re-enter the username and password.
Then start the AgilePoint Server service (Right click the AgilePoint service in the Services Console > Start).
Also, check to make sure the path of the Enterprise Manager web.config is correct.
After this, launch the AgilePoint Windows Service Client Utility Tool and try again.
I was asked this question:
| I am trying to reference the Ascentn Web Service per the documentation: http://myserver:9000/AgilePointServer/Workflow.asmx?WSDL I first referenced the web service as a "Web Reference", according to the instructions here: http://crm.davidyack.com/journal/2007/10/21/referencing-web-services-with-visual-studio-2008.html But, when I compile the proxy, I get all sorts of "duplicate definition" errors. For example: "The namespace Workflow.Workflow already contains a definition for category". I then referenced the web service as a "Service Reference", the Visual Studio 2008 default. However, I still get similar errors when compiling the proxy. Suggestions? |
By default, the option of Web Reference is not displayed in the Solution Explorer. As mentioned in the link, right click “Service Reference”, then choose “Add Service Reference ..”, do not enter the WSDL URL in the “Add Service Reference” windows, but instead, click on the “Advance” button at the bottom of the windows. Then, click on “Add Web Reference” on the next screen. After that, just enter the AgilePoint web service URL, click “Go” then add the web reference.
This is an build error (Envision installer) with below message:
“ERROR: Unable to update the dependencies of the project.”
No other info about the dependencies is available in the error message.
The behavior is it can be built in IDE, but can’t be built using command line devenv.
Microsoft acknowledged this is a bug and provided an hotfix. Apply below hotfix shall solve the issue.
More details for the VS.NET 2010 bug:
https://connect.microsoft.com/VisualStudio/feedback/details/552799
Hotfix:
http://connect.microsoft.com/VisualStudio/Downloads/DownloadDetails.aspx?DownloadID=30681
View > Custom Process Properties
This command displays the Custom Process Properties dialog. This window is also a convenient way to review all of the different values used within the entire process from a single location.
The dialog also allows you to add and/or remove custom values to the drop-down lists displayed (in the Activity Properties toolbar) next to certain AgileShape properties.
Adding custom process property values provides a convenient way to easily define common values that will be used (for certain AgileShape properties) in multiple AgileShapes.
For example, adding two new “WorkPerformer” values (as shown below) will cause both values to appear in the drop down list for the Work To Perform property (as shown below) for all of the Manual and Manual with Timeout AgileShapes in the process template.
AgilePoint provides you the flexible framework that you can write your custom Manual Activity, i.e. AglieWork. In the case that you need to obtain the overdue work items of the assigned participant, here is the sample code that you can use to grab the overdue work items as WFManualWorkItem objects.
private void MyAgileWork_WorkItemOverdue(Object sender, System.EventArgs e)
{
// TODO
Logger.WriteLine("MyAgileWork_WorkItemOverdue, Activity Instance={0}", base.m_ActivityInstance.DisplayName);
Logger.WriteLine("Check Number of WorkItems…");
Logger.WriteLine("WFManualWorkItemEventArgs args = e as WFManualWorkItemEventArgs");
WFOverdueWorkItemEventArgs args = e as WFOverdueWorkItemEventArgs;
WFManualWorkItem w = args.WorkItem as WFManualWorkItem;
}
One of the AgilePoint Integration for SharePoint features is that, the process is cancelled once the document is moved to target library.
In some cases, the users may want to keep the process running even the document is moved to another library. The solution for this is to associate the same process template at the target library.
Here is the issue:
Environment:
a) Two AgilePoint Servers in VMWare ESX virtual environment.
b) Cisco NLB device for network load balance
c) Two SharePoints on physical machine in NLB
Symptom:
AgilePoint task list web part on SharePoint works or not work sometime.
- Error message from web part: Unable to connect AgilePoint Server. Verify the Impersonator credentials in AgilePoint Configuration List
- Check AgilePoint SharePoint log file, it HTTP 401, Unauthorized
Steps to solve the issue:
STEP1:
a) Run TestWSConn.exe (AgilePoint test tool for cluster) and connects local AgilePoint Server – worked fine
b) Run TestWSConn.exe on SharePoint machine and connects one of remote AgilePoint Servers directly (no cluster name/IP) – HTTP 401, Unauthorized
c) Run setspn.exe, TestWSConn.exe worked from remote machine
STEP2
a) Run TestWSConn.exe on SharePoint machine A and connects AgilePoint Server using cluster name/IP -- worked fine
b) Run TestWSConn.exe on SharePoint machine B and connects AgilePoint Server using cluster name/IP -- HTTP 401, Unauthorized
c) Reset IIS of AgilePoint Servers. It worked on SharePoint B, but not on SharePoint A.
d) Switch non-sticky mode to sticky mode on Cisco NLB device. Both A and B worked fine.
Challenge from customer in this case:
Usually, the team we worked with does not have permission to configure the machine, device and Windows. So they are reluctantly to bother administrator of network, domain, virtual environment. They would try to prove the issue is caused by AgilePoint product. Here is the challenge:
a) They show you the cluster name/IP works on IE by browsing AgilePoint Server web service --- means web service works fine
Answer: browsing web service wsdl does not go through authentication, so it does not prove the authentication is fine.
b) They show EnterpriseManager works fine --- means configuration is OK
Answer: EntepriseManager is form authentication and connect to local AgilePoint Server. It does not prove authentication from remote machine is OK
c) They tell you the administrator has set principle name by running setspn.exe
Answer: deploy a generic test.asmx to two web appl one with LocalSystem and other one with AgilePoint Server AppPool (service account)
If one with LocalSystem works, but does not work AgilePoint Server AppPool. That proves principle name is not set correctly.
*Notice, LocalSystem does not need principle name
*test.asmx is a simple file with simple and generic web service of Hello()
d) They say the testing environment work fine in VMWare virtual environment --- meaning virtual environment does not have problem
Answer: In this case, the SharePoint and AgilePoint are on one single machine. It is local connection. Run TestWSConn.exe from workstation machine and connects to testing AgilePoint Server, not working. That proves VMWare environment has same problem.
Strategy for troubleshooting,
In general, NLB troubleshooting is hard because it could be hidden root cause or multiple cause. In this case, it was VMWare network driver, setspn and Cisco NLB configuration. Setting expectation at beginning is very important:
a) Troubleshooting may take long time. In this case, it took a week from beginning to end, total hour is 7 hours. Because the team needs to get help from other team. That takes days some time.
b) We are not expert of database DBA, not hardware engineer, not domain/network administrator and Cisco NLB expert. What we can do is to narrow down the problem and provide useful information and direction to customer.
Any proof in generic way would be easier to convince customer that is not AgilePoint issue. For example, deploy a generic and simple web service to prove principle name is not configured correctly. Customer would understand immediately and they are willing to get other team’s help.
I have a client that run into this issue. In Windows 7, my client is not able to connect to AgilePoint Server from Envision. But there is no problem to connect to AgilePoint Server from a Windows XP machine using Envision. In this case, disabling UAC in the Windows 7 machine solves the issue.
Here is how to disable the UAC.
Run cmd “msconfig” and you will see following window. Select ‘Change UAC Setting’, then click on the Launch button.
In order to disable UAC, make sure the slider control is at the bottom as shown below.
Also check Event Viewer Permission and make sure current logged on user is administrator has has full control on Event Viewer.
When designing a List Form AgilePoint process, it is common that you will add on more fields along the way building the process model. Here is how you add more fields after the List Form process template is created.
Go to File > SharePoint … > Retrieve Meta Data Schema.
Then select the fields available. You can also specified if you want the field to be editable, read only or hidden on your list form UI.
A client of mine tried to configure a remote Exchange Server in AgilePoint Server Configuration windows (see picture below), but it always failed to connect when clicking on the Test button.
In this case, for SMTP server you have to put the IP address or FQDN, not the OWA http url.
SharePoint Integration v1 MSI installer does not deploy ListForms Integration. This is because ListForms Integration is introduced after the distribution of SharePoint Integration v1 MSI has been stopped. User has a choice to install the ListForms manually using the stsadm command line tool.
But, if somehow you manually deploy the ListForms wsp to SharePoint and the deployment is not complete, then the upgrade installer is not able to upgrade for you.
For example, in this test environment, the ListForms wsp is found in the SharePoint solution store, but the it is not deployed (check this using enumsolutions command, and look for the <Deployed> element for ListForm, i.e. <Deployed>FALSE</Deployed>, see picture below).
If you run the upgrade installer, it gives you below errors in the upgrade log.
Default location of the upgrade log is YourDrive:\Program Files\AgilePoint\Upgrade\xxxxx[PickTheLatest]xxxxx\upgrade.log
4/13/2011 12:15:38 PM>>stsAdmProcess.StartInfo.Arguments: -o upgradesolution -name Ascentn.SharePoint.ListForm.wsp -filename "C:\Documents and Settings\Administrator\Local Settings\Temp\ckz_ACHE\NET20\SharePointv1\Web Parts\Ascentn.SharePoint.ListForm.wsp" -immediate -allowgacdeployment
4/13/2011 12:15:40 PM>>SharePoint Integration v1: Error, Solution "ascentn.sharepoint.listform.wsp" is not deployed. To upgrade the solution in the configuration database, omit the -time, -immediate, and -local flags. To then deploy to the front end, use the deploysolution command.
4/13/2011 12:15:40 PM>>SharePoint Integration v1: Information, Adding solution Ascentn.SharePoint.ListForm.wsp to the SharePoint ...
4/13/2011 12:15:56 PM>>SharePoint Integration v1: Error, A solution with the same name "ascentn.sharepoint.listform.wsp" or id "1f0a6833-6b4a-417b-9d6b-52d0fbbf21dd" already exists in the solution store.
C:\Documents and Settings\Administrator\Local Settings\Temp\ckz_ACHE\NET20\SharePointv1\Web Parts\Ascentn.SharePoint.ListForm.wsp: The Solution installation failed.
To solve this, simply manually clean up the ListForms wsp from SharePoint by running deletesolution, and then run enumsolutions to make sure the ListForms wsp is not in the solution store anymore.
stsadm -o deletesolution -name Ascentn.SharePoint.ListForm.wsp
stsadm -o enumsolutions
After that, run the upgrade installer again.
The upgrade installer will try to upgrade the solution first. If the upgrade is unsuccessful, which means there is no existing ListForms solution, then it will add the ListForms solutions. See log below.
4/13/2011 2:08:19 PM>>SharePoint Integration v1: Information, Upgrading solution Ascentn.SharePoint.ListForm.wsp in SharePoint ...
4/13/2011 2:08:19 PM>>stsAdmProcess.StartInfo.Arguments: -o upgradesolution -name Ascentn.SharePoint.ListForm.wsp -filename "C:\Documents and Settings\Administrator\Local Settings\Temp\ckz_ACHE\NET20\SharePointv1\Web Parts\Ascentn.SharePoint.ListForm.wsp" -immediate -allowgacdeployment
4/13/2011 2:08:24 PM>>SharePoint Integration v1: Information, "Ascentn.SharePoint.ListForm.wsp" does not exist in the solution store.
4/13/2011 2:08:24 PM>>SharePoint Integration v1: Information, Adding solution Ascentn.SharePoint.ListForm.wsp to the SharePoint ...
4/13/2011 2:08:38 PM>>SharePoint Integration v1: Information,
Operation completed successfully.
4/13/2011 2:08:38 PM>>Copying application bin content...
4/13/2011 2:09:12 PM>>Application bin content copied successfully
4/13/2011 2:09:24 PM>>SharePoint Integration v1: Information,
Executing .
Operation completed successfully.
4/13/2011 2:09:24 PM>>execadmsvcjobs, bSuccess = True
4/13/2011 2:09:24 PM>>Updating SharePoint Integration v1 ... finished
The details of deploying the ListForms manually is available in the v5.0 Installation Guide, page 10, 2.1.1.3 Additional Manual Upgrade Steps, 2.1.1.3.1 SharePoint ListForm.
Updated 04/14/2011
Changes made to the upgrade installer: the installer will try to upgrade using –immediate switch first, if it fails, that means the listform wsp is added to the solutions store, but user has not run the required manual step to deploy the listform wsp to desired sites. Refer to Installation Guide to for the manual steps.
4/14/2011 10:42:38 AM>>SharePoint Integration v1: Information, Upgrading solution Ascentn.SharePoint.ListForm.wsp in SharePoint ...
4/14/2011 10:42:38 AM>>stsAdmProcess.StartInfo.Arguments: -o upgradesolution -name Ascentn.SharePoint.ListForm.wsp -filename "C:\Documents and Settings\Administrator\Local Settings\Temp\ckz_ACHE\NET20\SharePointv1\Web Parts\Ascentn.SharePoint.ListForm.wsp" -immediate -allowgacdeployment
4/14/2011 10:42:40 AM>>SharePoint Integration v1: Information, Solution "ascentn.sharepoint.listform.wsp" is not deployed. To upgrade the solution in the configuration database, omit the -time, -immediate, and -local flags. To then deploy to the front end, use the deploysolution command.
4/14/2011 10:42:40 AM>>Omitting -immediate switch...
4/14/2011 10:42:40 AM>>SharePoint Integration v1: Information, Upgrading solution Ascentn.SharePoint.ListForm.wsp in SharePoint ...
4/14/2011 10:42:40 AM>>stsAdmProcess.StartInfo.Arguments: -o upgradesolution -name Ascentn.SharePoint.ListForm.wsp -filename "C:\Documents and Settings\Administrator\Local Settings\Temp\ckz_ACHE\NET20\SharePointv1\Web Parts\Ascentn.SharePoint.ListForm.wsp" -allowgacdeployment
4/14/2011 10:42:49 AM>>SharePoint Integration v1: Information, Solution "ascentn.sharepoint.listform.wsp" is not deployed. It is upgraded in the configuration database. To deploy to the front end machines, use the Deploy method.
4/14/2011 10:42:49 AM>>Ascentn.SharePoint.ListForm.wsp is added to the solution store, but not deployed. Refer to the Installation Guide for manual steps to deploy Ascentn.SharePoint.ListForm.wsp.
4/14/2011 10:42:49 AM>>Copying application bin content...
4/14/2011 10:43:06 AM>>Application bin content copied successfully
4/14/2011 10:43:15 AM>>SharePoint Integration v1: Information,
Executing .
Operation completed successfully.
4/14/2011 10:43:15 AM>>execadmsvcjobs, bSuccess = True
4/14/2011 10:43:15 AM>>Updating SharePoint Integration v1 ... finished
My work desktop just crashed, so I reinstalled the Window XP OS. For some reason, I am not able to access any site under microsoft.com. The sites on other domain names can be loaded fine.
It turned out that, the solution is to turn off a Windows Service call 'DNS Client'. See picture below.
One of my clients run into this issue. The error 'No config item was found for category 'AgilePoint' and key 'ServerUrl'.' is found at the event viewer of the SharePoint machine (See detail error message below). Upon further inspection at the AgilePoint Configuration List, some of the column names in the list appear to be "$Resources:Column_xxxx" instead of the correct display names. See screen shot below.
This is due to the content files of the AgilePoint Configuration List feature are not copied properly during upgrade or deployment of the feature. Running the stsadm command of copyappbincontent shall fix this issue.
stsadm –o copyappbincontent
Event Viewer Log:
Event Type: Error
Event Source: Utility.GetAPWorkflowService()
Event Category: None
Event ID: 0
Date: 1/25/2011
Time: 11:52:48 PM
User: N/A
Computer: CORPSP03
Description:
Message: No config item was found for category 'AgilePoint' and key 'ServerUrl'.
StackTrace: at Ascentn.SharePoint.SettingsList.AgilePointSettingsManager.GetValue(String application, String key, Guid siteId, Boolean bIgnoreErrors)
at Ascentn.SharePoint.SettingsList.AgilePointSettingsManager.GetValue(String application, String key, Guid siteId)
at Ascentn.SharePoint.Common.SPUtil.GetWorkflowService(Guid siteid)
Source: Ascentn.SharePoint.SettingsList
DETAILS:
System.Exception: No config item was found for category 'AgilePoint' and key 'ServerUrl'.
at Ascentn.SharePoint.SettingsList.AgilePointSettingsManager.GetValue(String application, String key, Guid siteId, Boolean bIgnoreErrors)
at Ascentn.SharePoint.SettingsList.AgilePointSettingsManager.GetValue(String application, String key, Guid siteId)
at Ascentn.SharePoint.Common.SPUtil.GetWorkflowService(Guid siteid)
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp
The WCF AgilePart is an out of the box shape available in the Premier stencil. It allows you to make a call to a WCF service in of the steps (activities) in your workflow.
The documentation of this AgilePart is available as part of the Envision Online Help.
The WCF AgilePart is working fine against Authenticated WCF Service. The following scenarios are tested:
1. Anonymous WCF Service : SUCCESS . WCF AgilePoint Server call Works fine.
2. Windows Authenticated WCF Service with custom credentials : SUCCESS. WCF AgilePoint Server call Works fine.
3. Windows Authenticated WCF Service with AgilePoint System User : Partially Success. In runtime the AgilePoint System user works fine, but in design time somehow the WFSystem.GetSystemUserCredential() does not return the proper credential object, I can not see the domain & password while design time debugging, but in runtime WFSystem.GetSystemUserCredential() returns proper credentials.
It turned out that, this is expected behavior. At design time you cannot use AgilePoint System User credentials since that is available only on the server. For design time, a specific credential has to be set. This is how even WSE works.
This is an example on how to use the Manage Code C# Shape in the Advance stencil to send email with attachment.
Insert below code snippet in the code editor of the Manager Code C# Shape in Envision. You may obtain the example of vsd file here.
In this example, the attachment file is located under the virtual directory of AgilePoint Server, which AgilePoint Server has no problem to access the file. If you want to use other location, make use AgilePoint Server Application Pool has enough privilege to access the location of your attachments.
using System;
using System.Collections;
using System.Data;
using System.Xml;
using System.Net;
using System.IO;
using System.Text;
using Ascentn.Workflow.Base;
namespace ManagedCode
{
public class CSharpCodeSnippet
{
// Invoke method is this class's entry point
public void Invoke(
WFProcessInstance pi,
WFAutomaticWorkItem w,
IWFAPI api,
NameValue[] parameters)
{
string emailAddress = WFSystem.SysAdmEMailAddress;
string attachment = WFSystem.HomeDirectory + "\\License.en-US.RTF";
IWFActivityInstance ai = api.GetActivityInst(w.ActivityInstID);
api.SendMail(
pi,
ai,
emailAddress,
null,
string.Format("Request for Approval - {0}", pi.ProcInstName),
"You are assigned with this task, please review and approve within two days.",
attachment);
}
}
}
Debugging:
Make use of AgilePoint Server log located at [AgilePointVirtualDirectory]\AgilePointServer\log for debugging. For example, if your attachment file is missing, you can find error log below in AgilePoint Server log.
7/1/2009 09:49:36 >>> Send Mail, attaching file does not exists, file='C:\AgilePoint\AgilePointServer\License.RTF', ID='2AD5BB44AE5B42DF94F6492BF744C2A2'
In SharePoint Integration v2, AgilePoint Configuration List is needed at the top level site to store the info for AgilePoint Server (URL, username, password, etc).
With this, you need to configure this list for each site collection you have.
If you have hundreds of site collections, configuring and maintaining hundreds AgilePoint Configuration List for site collections are just not efficient.
Here is a way you can configure a centralized AgilePoint Configuration List that can be shared by all the site collections in a SharePoint farm.
Insert below entries in the web.config file of your SharePoint web application.
<appSettings>
<add key="APSettingsListName" value="AgilePoint Configuration" />
<add key="APSettingsSiteUrl" value="http://demo3:8081" />
<add key="APSettingsWebName" value="" />
</appSettings>
Where:
APSettingsListName = The name of the AgilePoint Settings List.
APSettingsSiteURL = The SharePoint SiteURL that contains the common AgilePoint Configuration List. The rest of the site collections will refer to this location and list as long as the individual AgilePoint Configuration list (which is auto-created in the site collection when this feature is activated) is deactivated or removed.
APSettingsWebName = If this field is left blank, this means that the AgilePoint Configuration List is located at the top-level site. A value would indicate the Sub site name.
After this, you might just goes ahead to activate the "AgilePoint Process Launcher" feature, so that process can be triggered for items inserted into the SharePoint. But, you will run into below error:
To fix this, you may remove the ActivationDependencies node (see below) from the feature file of "AgilePoint Process Launcher". The feature file is located at C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\FEATURES\AgilePointWFIntegration\feature.xml.
<ActivationDependencies>
<ActivationDependency FeatureId="A379136F-8742-4f0c-9D5A-9310A4D2B80C"/>
</ActivationDependencies>
This shall let you to activate the "AgilePoint Process Launcher" feature without needing to activate the 'AgilePoint Configuration List' feature on each site collections.
This is for both of the cases of upgrading SharePoint Integration using the upgrade installer and also manually using the stsadm tool. If you see error below, that means there are previously run command to upgrade the solution files for SharePoint Integration, but the deployment was not completed for certain reason and stuck at that point.
Below is the log of upgrading using the upgrade installer. It's the same error for the case of upgrading manually using the stsadm tool.
1/28/2011 11:05:07 AM>>Updating SharePoint Integration v2... started
1/28/2011 11:05:07 AM>>StartDeployment start
1/28/2011 11:05:07 AM>>SharePoint Integration v2: Information, Upgrading solution Ascentn.SharePoint.SettingsList.wsp in SharePoint ...
1/28/2011 11:05:07 AM>>stsAdmProcess.StartInfo.Arguments: -o upgradesolution -name Ascentn.SharePoint.SettingsList.wsp -filename "C:\Documents and Settings\Administrator\Local Settings\Temp\ckz_1OML\NET20\SharePointv2\Ascentn.SharePoint.SettingsList.wsp" -immediate -allowgacdeployment
1/28/2011 11:05:23 AM>>SharePoint Integration v2: Error, A deployment or retraction is already under way for the solution "ascentn.sharepoint.settingslist.wsp", and only one deployment or retraction at a time is supported.
You may use the following steps to cancel the uncompleted jobs, then run the upgrade installer again or run the upgradesolution command again if upgrade manually.
Run enumdeployments command to get the job IDs:
stsadm -o enumdeployments
The return string looks like this:
<Deployments Count="4">
<Deployment JobId="71d06ccb-f5d9-4ae5-8caf-7223130c2a70">
<Title>Windows SharePoint Services Solution Deployment for "ascentn.sharepoint.listform.wsp"</Title>
<Type>Upgrade</Type>
<State>Failed</State>
<File>ascentn.sharepoint.listform.wsp</File>
<ServerType>Front-end Web server</ServerType>
</Deployment>
<Deployment JobId="962557ba-21e7-4739-9b6e-3e38446b477d">
<Title>Windows SharePoint Services Solution Deployment for "ascentn.sharepoint.settingslist.wsp"</Title>
<Type>Upgrade</Type>
<State>Failed</State>
<File>ascentn.sharepoint.settingslist.wsp</File>
<ServerType>Front-end Web server</ServerType>
</Deployment>
<Deployment JobId="add88985-159a-493f-a6f3-26f8918f6517">
<Title>Windows SharePoint Services Solution Deployment for "ascentn.sharepoint.webparts.wsp"</Title>
<Type>Upgrade</Type>
<State>Failed</State>
<File>ascentn.sharepoint.webparts.wsp</File>
<ServerType>Front-end Web server</ServerType>
</Deployment>
<Deployment JobId="08fb8dac-a290-4466-966d-b06fab38b465">
<Title>Windows SharePoint Services Solution Deployment for "ascentn.sharepoint.wfintegration.wsp"</Title>
<Type>Upgrade</Type>
<State>Failed</State>
<File>ascentn.sharepoint.wfintegration.wsp</File>
<ServerType>Front-end Web server</ServerType>
</Deployment>
</Deployments>
Then, run the canceldeployment command to cancel all the uncompleted jobs related to AgilePoint SharePoint Integration.
stsadm -o canceldeployment -id "GUID jobId"
After this, you may run the enumdeployments command again to check the jobs are canceled.
stsadm -o enumdeployments
At this point, you are good to run the upgrade installer or upgradesolution command again.
If you are getting the 'SPSecurity.RunWithElevatedPrivilages()' error at SharePoint (see picture below), that means the application pool identity of your SharePoint web application does not have enough privilege to write to the event viewer on your SharePoint machine. Your network administrator shall be able to help you with this. If you need more details, the Pre-Installation Guide and Installation provide you the full details for SharePoint installation. This error is not caused by AgilePoint.
We had made things a bit more seamless and easy in 5.0 SP1 release as far as cluster is concerned so I have listed both approaches based on whether you want to stay on 5.0 release of AgilePoint or want to upgrade to 5.0 SP1.
Irrespective of which option you go for make sure following things are done in your environment which are pre requisites of any NLB app
1) Make sure web.config of AgilePoint Server and Enterprise Manager has SessionState set to SQLServer. For example,
<sessionState mode="SQLServer"
regenerateExpiredSessionId="true"
timeout="30"
sqlConnectionString="Server=<server-name>;Trusted_Connection=True;"
stateNetworkTimeout="30"/>
2) Ping from one machine to another, i.e. ping machine A from machine B and from B to A
3) Make sure firewall is off on both machine
If your CSM component needs to be installed on separate server outside AP server farm. This is what we supported till 5.0
1) Install AgilePoint CSM component on an server which is outside AgilePoint farm servers. It has a very small footprint so can be installed on any existing server like database server. It does not need dedicated machine of its own.
2) Activate both AgilePoint servers with NLB keys.
3) Open AgilePoint Server Configuration utility. You will start seeing a new field for cluster server manager. You need to replace machine name with name of machine where you installed CSM component. Save configuration and reset IIS. Do this on both machines.
4) Once you have done step 3 on both servers, you can go to machine where you installed CSM and we provide a utility there to test your NLB is working fine or not. If you have an old installation, your folder name is 'Ascentn Corp'. If you have new installation, then 'AgilePoint' will be your folder name. I have an old installation in picture below. Once you run this as shown below you should get response from both machines. If you see that it means NLB is fine.
We were getting request from customers that can they install AgilePoint CSM on same machine as AgilePoint server so that they do not have to worry about managing it on other machine. In 5.0 SP1, we have added a new logic such that it can be hosted on same machine. Here is what you need to do.
1) Using 5.0 installer, install AgilePoint CSM on both AgilePoint servers. Use NLB keys for activation of both servers.
2) Upgrade both machines to AgilePoint 5.0 SP1 by running the upgrade package. This is a straight forward upgrade.
3) There is an entry to be made in the registry to point the CSM to AgilePoint database. This contains a connection string. In this case you do not have to set cluster server manager machine name as done in step 3 of option 1. The reason is that CSM is on that machine so it does not need this information separately.
You would need to manually create one registry key for option 2 since CSM is going to be on same machine as AP server. Here is the key which need to be created
In this registry value copy AgilePoint Database connection string to CSM registry. You can get this value from your netflow.cfg file. Please take note of the DB provided in front section of the connection string, e.g. MSSQLDatabase: connection lifetime=5;min pool size=10;server=T410-1;database=AgilePoint47;trusted_Connection=yes
4) Click ok on AgilePoint Configuration Utility and reset IIS. This needs to be done on both machines. Please note that in this case you should not see the cluster server manager textbox in AP configuration utility as in option 1. If you see that you need to delete one entry from registry or netflow.cfg file.
5) After making above entry on both machines, restart CSM (windows service on both machine). Please make sure that the logon identity for CSM windows service is having DBO privileges on AgilePoint database.
· Query database and make the CSM works, i.e. you can see WF_CLSUTER_SERVER_URI has one record.
If you see URL=machineA:13841, stop CSM window service on machine A and query again. You will see URL will be MachineB:13841.
· Now make sure both machine windows services are started. Run iisreset and check the AgilePont Server log file.
One machine will have:
010-11-07 16:51:12.688 >>> Initialize Cluster Event Dispatcher, uri=tcp://T410-006:13481/192.168.0.24/55a1a2b7-46cb-4148-a15f-a4e2a18d1b44:False
The other machine have:
2010-11-07 16:51:02.564 >>> Initialize Cluster Event Dispatcher, uri=tcp://T410-006:13481/192.168.0.24/97adaa57-8d82-47e9-aafb-f50c0c667a0c:True
Here, the 'True' means it is the master server.
6) Now use the ping utility to test for NLB as done in option 1
Both options do not take much time. Only difference is whether you want to install CSM on same machine or different machine.
How do I know if the AgileForms installed in my machine is the beta version or the released version?
If you have below registry key, that means you have the released version of AgileForms (v5.0 SP1). If this key does not exist in your environment, that means you have the beta version of AgileForms. It is recommended that you uninstall the beta version and install the release version. There is no upgrade from the beta version to the released version for now.
HKEY_LOCAL_MACHINE\SOFTWARE\BWS\AFEControl\AFVersion
A customer is working with InfoPath form with attachment. When the attachment size grows bigger and bigger, the process is suspended at the Update InfoPath Activity. See picture below.
I usually do not recommend to attach large attachment to InfoPath, because the whole xml of InfoPath is submitted to AgilePoint every time the user completes the task. The larger the attachment, the slower the data transfer between SharePoint and AgilePoint.
For large attachment, I suggest to keep that attachment file in a library in SharePoint, then keep the link of that attachment in the InfoPath form. Then user can still open up the attachment from the InfoPath form.
The other thing can be looked into is the maxRequestlength setting in the web.config of AgilePoint and SharePoint. See this KB. But this will not help much on the speed/performance if the file is too large. The bandwidth of the network actually becomes the bottleneck in this case.
AgilePoint Web Project provides a framework for your to develop your custom workflow web application with AgilePoint capability. In come cases, the base.CompleteWorkItem() at your aspx page does not complete the work items. Here is an alternative to call the CompleteWorkItem method.
Here is your code which calls the base.CompleteWorkItem():
private void SubmitClick(bool Approved)
{
NameValue[] nvs = new NameValue[] { new NameValue("/pd:myFields/pd:Approval", Approved) };
base.SetCustomAttrs((string)base.GetWorkObjectID(), nvs);
base.CompleteWorkItem();
....
}
You can override the CompleteWorkItem() method and call --> this.CompleteWorkItem() :
You may call the CompleteWorkItem() method from the WFWorkflowService object (it's represented by the variable api below) directly. Another benefit to do this is, you may inspect the WFEvent object returned from api.CompleteWorkItem() to see if it is failed or succeeded. (Note: base.CompleteWorkItem() return void, so you can't inspect the event status)
Please note that the loop in below code that waits for 1 second and checks the event status again is for testing or debugging purpose only. If you put this code in production every time you call the CompleteWorkItem() method, it might cost performance issue.
protected override void CompleteWorkItem()
{
// base.CompleteWorkItem(); <-- do not call the base method
if (base.GetWorkItemID() == null)
{
Logger.WriteLine("Lost Work item ID from ViewState[WID]...");
// ToDo: You might want to provide an alert message here
}
base.WriteBindingControls();
if (base.GetAPI() == null)
{
Logger.WriteLine("Lost API from the SessionState...");
// ToDo: You might want to provide an alert message here
}
IWFWorkflowService api = base.GetAPI();
WFEvent evt = api.CompleteWorkItem(base.GetWorkItemID()); // Submit Complete Work Item
System.Threading.Thread.Sleep(1000); // 1 sec wait
WFEvent evtUpdt = api.GetEvent(evt.EventID);
while (evtUpdt.Status == WFEvent.SENT) // Inspect event status
{
System.Threading.Thread.Sleep(1000); // 1 sec wait
evtUpdt = api.GetEvent(evtUpdt.EventID);
}
if (evtUpdt.Status == WFEvent.FAILED)
{
Logger.WriteLine("Failed Work Item Completion request xxxxx - Check AP Server Log");
// Potential errors that can be gleaned from the AP Server Log are:
// 1. Ownership of the workitem - requester is different from the assigned user
// i.e. Failed to complete the task due to ownership with Request User={0} and Assigned User={1}
// 2. UserID for the work item is null
// i.e. Failed to complete the task with WorkItemID={0} because there is no assigned user.
// 3. Work Item has null Activity Instance ID
// i.e. Failed to create work item because the activity is not found with process='{0}',ActivityID={1}, and Sender='{2}'
// 4. this work item depends on child work items
// i.e. Failed to complete work item because he work item is trying to be completed depends on child work item(s), Process='{0},{1}/{2}/ID={3}' WorkItemID='{4}', Child WorkItemID='{5}'
}
else if (evtUpdt.Status == WFEvent.PROCESSED)
{
Logger.WriteLine("Processed Work Item Completion request xxxxx");
}
}
In this case, the following error appears many times in the Event Viewer.
InfoPath Forms Services has detected a mismatch between the user's data in the browser and on the server. This may indicate the SESSION_STATE_PASCAL_CASED is not configured properly on a multiple front end farm or that a malicious user is trying to tamper with client data. (User: MYDOMAIN\username123, Form Name: ABCForm, IP: , Request: http://myserverXYZ/_layouts/Postback.FormServer.aspx, Form ID: urn:schemas-microsoft-com:office:infopath:ABCForm:-myXSD-2005-10-21T21-12-27)
This is a common SharePoint issue that your SharePoint admin would be able to help. This error also happens when the shared service in SharePoint central admin is not configured properly. After creating a new shared service, that error went away.
You may also try the following. Clear browser's cache and try again and if that doesn't solve the problem then run the following command:
stsadm -o reconvertallformtemplates
See this link for more details.
Your SP admin would be best person to help with this. This is not related to AgilePoint as such.
The Setup Project in Visual Studio .Net provides you a convenience way to check the pre-requisite .NET Framework version required before allowing your installation takes place. But, there are only limited .Net version that are available. See picture below for available .Net Framework versions.
For example, if you need to check .NET Framework 3.5 SP1, then the Setup Project can't check that for you. In this case, you need to write custom code to check the registry entry for 3.5 SP1. Refer to article below for the registry entries of .NET Framework.
How to determine which version and service pack levels of Microsoft .NET Framework are installed
Knowing the locations of log files comes very useful when you are facing issue and trying to troubleshoot.
[VirtualServerDirectory]\AgilePointServer\log, e.g. C:\BPMWebSite\AgilePointServer\log
If you see a general error message at SharePoint, e.g. 'Unknown Error' with a 'Go back to site' link, see pictures below, you can see the full error thrown by SharePoint by modifying a few entries in the web.config of SharePoint web application, i.e. the stack trace, the debug mode and the custom error mode. Search and set following values. It will let you know exactly what failed. Remember to backup your web.config before any changes.
For SharePoint 2010, you need to modify this in two web.config files, i.e. the web.config of SharePoint web application root (e.g. C:\inetpub\wwwroot\wss\VirtualDirectories\12345YourPortNumber), and also the web.config under the layout folder (C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\LAYOUTS).
Do this:
For example:
<SafeMode MaxControls="200" CallStack="true" DirectFileDependencies="10" TotalFileDependencies="50" AllowPageLevelTrace="false">
<customErrors mode="Off" />
<compilation batch="false" debug="true">
General error page from SharePoint:
