I've got an approval process; in the sole Approval Step, there is a Field Update Approval Action, where it changes the record owner to a specified user. Then, in the Final Approval Actions, I have a [workflow] Task which is configured to be assigned to (and notify) the current record owner.
The intention is that, upon approval, the record owner is changed, and a task is assigned to the new record owner.
However, it appears that at least one of the Final Approval Actions (task creation) is occurring before the Approval Step's Approval Action (change of record ownership). The task is being assigned to the record owner before the ownership is changed. Afterward, the owner has indeed changed, but it's too late.
Is this by design? Suggested workaround? Or have I configured it wrong?
I'm finding this error occurs when I include fields of type DateTime (for example, LastModifiedDate) on an outbound message. I've posted a snippet of the output from YATT stack trace below. BTW, I'm running Win2k3, IIS 6.0, .NET 2.0.
System.Web.Services.Protocols.SoapException: Server was unable to read request. ---> System.InvalidOperationException: There is an error in XML document (21, 73). ---> System.FormatException: String was not recognized as a valid DateTime. at System.DateTimeParse.ParseExactMultiple(String s, String[] formats, DateTimeFormatInfo dtfi, DateTimeStyles style) at System.DateTime.ParseExact(String s, String[] formats, IFormatProvider provider, DateTimeStyles style) at System.Xml.XmlConvert.ToDateTime(String s, String[] formats) at System.Xml.Serialization.XmlCustomFormatter.ToDateTime(String value, String[] formats) at System.Xml.Serialization.XmlCustomFormatter.ToDate(String value) at System.Xml.Serialization.XmlSerializationReader.ToDate(String value) at Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationReader1.Read2_NullableOfDateTime(Boolean checkType) at Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationReader1.Read5_MY_CUSTOM_SOBJECT__c(Boolean isNullable, Boolean checkType) at Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationReader1.Read7_MY_CUSTOM_SOBJECT__cNotification(Boolean isNullable, Boolean checkType) at Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationReader1.Read8_notifications(Boolean isNullable, Boolean checkType) at Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationReader1.Read10_notifications() at Microsoft.Xml.Serialization.GeneratedAssembly.ArrayOfObjectSerializer.Deserialize(XmlSerializationReader reader) at System.Xml.Serialization.XmlSerializer.Deserialize(XmlReader xmlReader, String encodingStyle, XmlDeserializationEvents events) --- End of inner exception stack trace --- at System.Xml.Serialization.XmlSerializer.Deserialize(XmlReader xmlReader, String encodingStyle, XmlDeserializationEvents events) at System.Xml.Serialization.XmlSerializer.Deserialize(XmlReader xmlReader, String encodingStyle) at System.Web.Services.Protocols.SoapServerProtocol.ReadParameters() --- End of inner exception stack trace --- at System.Web.Services.Protocols.SoapServerProtocol.ReadParameters() at System.Web.Services.Protocols.WebServiceHandler.CoreProcessRequest()
Now, I was able to work around this by 1) removing the DateTime
field(s) from the outbound message--which enables the serialization to work and let the web service code proceed to execute--and then 2) using "retrieve" to get
the field when its needed in runtime. Alas, this results in an extra
round-trip, which is unfortunate. At least it works for now.
Any
other suggestions? I'm sure others will encounter this at some point.
Can anyone suggest a general approach to converting an enterprise sObject (as received by an outbound message, for example) to a partner sObject?
Our codebase is built around the partner WSDL, and now we're consuming outbound messages, which of course provide strongly-typed enterprise sObjects.
Yes, I could use the .NET reflection APIs, but at the risk of prematurely optimizing for performance, I'd like to find a less expensive operation, and yet still be reasonably generic and flexible.
We'd like to trigger an outbound message on an object and then take action based on whether or not a particular field has changed.
Does this require storing the previous state of the object and comparing it to the new state, or is there some built-in mechanism to determine which field on an object has changed?
We can compare the current state of an object to an older version if we keep a copy of the data in a database, but it would be ideal to avoid this, obviously.
If this is not available, are there any plans for a future release? It would be great if, for example, each field in an outbound message could have a flag indicating that its value has just changed.
Is there a recommended approach for the using the API to assign approvers? Here's our scenario:
We have an approval process that requires a manager, vice-president, and president's approval. So, we have an approval process with three approval steps.
The manager and vice-president vary, so the corresponding user ids must be assigned programmatically. (We cannot use the "Step 3. Select Assigned Approver" option to specify the user who should approve records that enter this step. We also cannot allow either the submitter or the approving user to manually choose the next user.)
I've created an Outbound Message -- fairly simple, on a custom object, passing three object Id fields -- and in the process of testing it, the outbound message ends up as a failure in the queue as noted on the Outbound Messaging Delivery Status page.
The error is org.xml.sax.SAXParseException: White spaces are required between publicId and systemId.
It may be related to the fact that I've set the SOAP endpoint to localhost, which is obviously non-routable. (Duh...) Still, it may be related to something else entirely.
Some questions related to the new 8.0 API. (And thanks for an excellent pre-release!)
1. Does the sforce explorer (using DescribeSObjects, etc) return all the correct metadata for the org when configured to use the 8.0 SOAP endpoint? (https://prerelna1.pre.salesforce.com/services/Soap/u/8.0)
2. If so, then why does it indicate that the ProcessInstance is query-able and retrieve-able, whereas the API Docs indicate that they are more accessible (create, delete, query, retrieve, update, upsert)?
Granted, I could write a quick test to try it and find out, but I thought it would be useful to point out the discrepancy just in case.
Thanks again for some incredibly useful new features. Only problem is that we just spent a few weeks working around limitations in 7.0 that have almost all been resolved with 8.0! :-)
I've got an approval process; in the sole Approval Step, there is a Field Update Approval Action, where it changes the record owner to a specified user. Then, in the Final Approval Actions, I have a [workflow] Task which is configured to be assigned to (and notify) the current record owner.
The intention is that, upon approval, the record owner is changed, and a task is assigned to the new record owner.
However, it appears that at least one of the Final Approval Actions (task creation) is occurring before the Approval Step's Approval Action (change of record ownership). The task is being assigned to the record owner before the ownership is changed. Afterward, the owner has indeed changed, but it's too late.
Is this by design? Suggested workaround? Or have I configured it wrong?
I'm finding this error occurs when I include fields of type DateTime (for example, LastModifiedDate) on an outbound message. I've posted a snippet of the output from YATT stack trace below. BTW, I'm running Win2k3, IIS 6.0, .NET 2.0.
System.Web.Services.Protocols.SoapException: Server was unable to read request. ---> System.InvalidOperationException: There is an error in XML document (21, 73). ---> System.FormatException: String was not recognized as a valid DateTime. at System.DateTimeParse.ParseExactMultiple(String s, String[] formats, DateTimeFormatInfo dtfi, DateTimeStyles style) at System.DateTime.ParseExact(String s, String[] formats, IFormatProvider provider, DateTimeStyles style) at System.Xml.XmlConvert.ToDateTime(String s, String[] formats) at System.Xml.Serialization.XmlCustomFormatter.ToDateTime(String value, String[] formats) at System.Xml.Serialization.XmlCustomFormatter.ToDate(String value) at System.Xml.Serialization.XmlSerializationReader.ToDate(String value) at Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationReader1.Read2_NullableOfDateTime(Boolean checkType) at Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationReader1.Read5_MY_CUSTOM_SOBJECT__c(Boolean isNullable, Boolean checkType) at Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationReader1.Read7_MY_CUSTOM_SOBJECT__cNotification(Boolean isNullable, Boolean checkType) at Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationReader1.Read8_notifications(Boolean isNullable, Boolean checkType) at Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationReader1.Read10_notifications() at Microsoft.Xml.Serialization.GeneratedAssembly.ArrayOfObjectSerializer.Deserialize(XmlSerializationReader reader) at System.Xml.Serialization.XmlSerializer.Deserialize(XmlReader xmlReader, String encodingStyle, XmlDeserializationEvents events) --- End of inner exception stack trace --- at System.Xml.Serialization.XmlSerializer.Deserialize(XmlReader xmlReader, String encodingStyle, XmlDeserializationEvents events) at System.Xml.Serialization.XmlSerializer.Deserialize(XmlReader xmlReader, String encodingStyle) at System.Web.Services.Protocols.SoapServerProtocol.ReadParameters() --- End of inner exception stack trace --- at System.Web.Services.Protocols.SoapServerProtocol.ReadParameters() at System.Web.Services.Protocols.WebServiceHandler.CoreProcessRequest()
Now, I was able to work around this by 1) removing the DateTime
field(s) from the outbound message--which enables the serialization to work and let the web service code proceed to execute--and then 2) using "retrieve" to get
the field when its needed in runtime. Alas, this results in an extra
round-trip, which is unfortunate. At least it works for now.
Any
other suggestions? I'm sure others will encounter this at some point.
Can anyone suggest a general approach to converting an enterprise sObject (as received by an outbound message, for example) to a partner sObject?
Our codebase is built around the partner WSDL, and now we're consuming outbound messages, which of course provide strongly-typed enterprise sObjects.
Yes, I could use the .NET reflection APIs, but at the risk of prematurely optimizing for performance, I'd like to find a less expensive operation, and yet still be reasonably generic and flexible.
We'd like to trigger an outbound message on an object and then take action based on whether or not a particular field has changed.
Does this require storing the previous state of the object and comparing it to the new state, or is there some built-in mechanism to determine which field on an object has changed?
We can compare the current state of an object to an older version if we keep a copy of the data in a database, but it would be ideal to avoid this, obviously.
If this is not available, are there any plans for a future release? It would be great if, for example, each field in an outbound message could have a flag indicating that its value has just changed.
currently I'm developing an SalesForce integration with a call application. This application provides an integrated webbrowser in which I want to load the normal SalesForce interface/application.
When a call is coming in, I want to automatically search for the account/contact who is calling in SalesForce.
Initially, I have done some investigating on the SF API which I can use. I can search directly some SQL statements for the necessary information. However, in that case I do need to develop an interface myself. What I basically want is that I use the complete SalesForce interface within my application, and that when I search for a Contact for example, that I display that contact information in SF the same way as when I've done a search in SF manually.
In that way, the user can work in SF whole day, with the standard interface, only they have another skin and additional functionality in the parent application.
As this is my first SF development, any help is appreciated. Btw, I want to develop it in ASP.NET
Is there a recommended approach for the using the API to assign approvers? Here's our scenario:
We have an approval process that requires a manager, vice-president, and president's approval. So, we have an approval process with three approval steps.
The manager and vice-president vary, so the corresponding user ids must be assigned programmatically. (We cannot use the "Step 3. Select Assigned Approver" option to specify the user who should approve records that enter this step. We also cannot allow either the submitter or the approving user to manually choose the next user.)
I've created an Outbound Message -- fairly simple, on a custom object, passing three object Id fields -- and in the process of testing it, the outbound message ends up as a failure in the queue as noted on the Outbound Messaging Delivery Status page.
The error is org.xml.sax.SAXParseException: White spaces are required between publicId and systemId.
It may be related to the fact that I've set the SOAP endpoint to localhost, which is obviously non-routable. (Duh...) Still, it may be related to something else entirely.
Some questions related to the new 8.0 API. (And thanks for an excellent pre-release!)
1. Does the sforce explorer (using DescribeSObjects, etc) return all the correct metadata for the org when configured to use the 8.0 SOAP endpoint? (https://prerelna1.pre.salesforce.com/services/Soap/u/8.0)
2. If so, then why does it indicate that the ProcessInstance is query-able and retrieve-able, whereas the API Docs indicate that they are more accessible (create, delete, query, retrieve, update, upsert)?
Granted, I could write a quick test to try it and find out, but I thought it would be useful to point out the discrepancy just in case.
Thanks again for some incredibly useful new features. Only problem is that we just spent a few weeks working around limitations in 7.0 that have almost all been resolved with 8.0! :-)
