I'm integrating our SF application with other in-house applications using the Outbound Messaging web service functionality. I want CRUD operations on the data in our SF.com application to be reflected in other integrated applications. It works great for scenarios where I'm creating or editing records - automatically generating outbound notifications. However, I've not been able to create a workflow rule (which outbound messages reply upon to trigger them) for deletion of records. I'm using standard objects, such as contact and account.
When creating a workflow rule, the 'evaluation criteria' is: When a record is created, or when a record is edited and did not previously meet the rule criteria Only when a record is created Every time a record is created or edited (I'm using this)
I would have expected that deleting a record would be identified as an edit in the above options? If not (and it seems not) how can I create a workflow rule to fire when a record is deleted? I.e. how to I create outbound messaging to autnocally fire for all CRUD operations (not just create and update)?
Also, what is the purpose of the IsDeleted flag in outbound notifications payload if it's not possible generate outbound notification with the IsDeleted flag set to anything other than false?! I'm not talking about the IsDeleted API here, I'm talking about outbound notification generated on an insert or update operation on a standard object)
The Salesforce.com Outbound Notification Web Services AP (App Setup / create / Workflow & Approvals / outbound Messages) creates a WSDL containing a Notification element that has a upperbound of 100;
I can't see an obvious configuration change on the Outbound Message that would help. Does anyone know if there is any way of getting fieldsToNull populated ?
The net effect seems to be that if a Contact has 10 blank field values, and a new single (11th) field is blanked, the resulting notification will not specify which field was just blanked. It simply omits all the (optional) elements for all 11 blank fields ...
as opposed to writing java code, I'm using a java-based tool (Oracle BPEL) for calling the Web Services API. My use-case is simply to bi-directionally synchronize cloud-based Contact data with an in-house Contact Master.
For calls inbound to force.com, I have been advised by our force.com consulting partner to use the Partner WSDL (to insulate the middleware from configuration changes in the cloud). I have proof-of-concepted both WSDLs, and they both work fine. However, the partner API seems to me to have little value for my particular use case, as:
1) The tool I am using finds it much easier to transform messages when it has source and target XSDs/schemas. However, the Contact object's complex type is only in the Enterprise WSDL schema, and not in the Partner WSDL schema. Although I can use the Enterprise WSDL complex type to build the message and then copy the nodes to the appropriate Partner WSDL node, I don't see the value in that ... why not just use the Enterprise WSDL ?
2) Also, this is an in-house development for a single organization. I'm not trying to develop a multi-organizaiton product.
3) Finally, it seems to me that if contract-impacting configuration changes to custom fields are made in the Cloud (i.e. such as field renames or field deletes) that strong typing is an advantage - as it's better to fail than have things continue to operate in a possibly unintended fashion. So long as non-mandatory custom field additions in the cloud don't force me to rebuild my integrations, I'm happy, and I believe the Enterprise WSDL will not need to be rebuilt in this case.
which encourages me to use the Enterprise WSDL for my fairly simple use case. However, as I'm new to force.com, I'm hoping for some validation from some of the experts out there.
as opposed to writing java code, I'm using a java-based tool (Oracle BPEL) for calling the Web Services API. My use-case is simply to bi-directionally synchronize cloud-based Contact data with an in-house Contact Master.
For calls inbound to force.com, I have been advised by our force.com consulting partner to use the Partner WSDL (to insulate the middleware from configuration changes in the cloud). I have proof-of-concepted both WSDLs, and they both work fine. However, the partner API seems to me to have little value for my particular use case, as:
1) The tool I am using finds it much easier to transform messages when it has source and target XSDs/schemas. However, the Contact object's complex type is only in the Enterprise WSDL schema, and not in the Partner WSDL schema. Although I can use the Enterprise WSDL complex type to build the message and then copy the nodes to the appropriate Partner WSDL node, I don't see the value in that ... why not just use the Enterprise WSDL ?
2) Also, this is an in-house development for a single organization. I'm not trying to develop a multi-organizaiton product.
3) Finally, it seems to me that if contract-impacting configuration changes to custom fields are made in the Cloud (i.e. such as field renames or field deletes) that strong typing is an advantage - as it's better to fail than have things continue to operate in a possibly unintended fashion. So long as non-mandatory custom field additions in the cloud don't force me to rebuild my integrations, I'm happy, and I believe the Enterprise WSDL will not need to be rebuilt in this case.
which encourages me to use the Enterprise WSDL for my fairly simple use case. However, as I'm new to force.com, I'm hoping for some validation from some of the experts out there.
