Hi Patrick,
I don't have a lot of experience, but it is a rather straightforward thing to do...

The simple case is accessing custom fields in a standard object (e.g. you created a custom field in the Lead object). Even though I don't think this is what you're looking for, the process is rather similar:
- Change the Salesforce_Connector module, and add new Attributes (for each custom field) in the Structure that supports that object (Lead in this case). A custom field in salesforce should be named with a "__c" suffix (that's the name of the custom field in salesforce when accessed through the API.

So assuming you had a "ToBeFollowedUpBy" datetime custom field in the Lead object, it would look something like this in the OutSystems structure:


Refresh your references to those structures... and you're done. No need to change the actions that work over that structure/object, as the fields that will be fetched/sent from/to salesforce will be determined from the attributes.

Now... what about a full blown custom object?
Very similar. But you'll want to create some helper functions, just like those we already have for the standard objects (Leads, Opportunities, etc). So let's follow a simple scenario.

Suppose I created a custom object in salesforce to track "Teams" (football teams). A simple list displaying it in salesforce looks like this:



Here's the definition with some important sections highlighted:

• The custom object API Name: Team__c
• A list of standard fields. Take a look at the "Field Name"
• A list of custom fields. Take a look at the "API Name" for each field

With this in mind, the next steps should be:

• Create a Structure that maps this custom object
• Duplicate the helper functions from a standard object, and change them to use the custom Structure instead.

The structure will look something like this:

• Notice the __c name suffix whenever you have a custom object/field
• And make sure you have the correct field types (e.g. Date Time on the Started_Playing field). 
• The Id should always be there...
• And you could copy paste some of the standard attributes from other Structures (e.g. CreatedById, CreatedDate, ...)

With this done, you could now copy/paste the entire Lead related set of actions:
I only created this small example by copying LeadsFind:



Change the Data Type of the inputs and outputs whenever it applies (in this case instead of returning a LeadRecordList, return a TeamRecordList, which is a Record List of the Team__c you just created).

TrueChange will refactor most of your logic automatically so you should be ok... take a look at any errors and/or data type warnings that popup - if you have any, you're probably missing changing some type...

With this done... use it just as any other salesforce action across your applications.



RAD it on!

Dear Goncalo,

Thank you for the elaborate explanation.   I will try this ASAP.

Hi everyone,

I've been able to follow the above instructions (thanks Gonçalo!) for a Custom Object and Fields. But then I came up with an issue when using a Custom Field with Master-Detail relationship to Account object. I get an Object reference not set to an instance of an object error...upon closer look this seems related to OutSystems Structure mapping inside SForce.xif extension project.

Any further clues to what I should look/fix?
Is the component ready for this Salesforce data type?

Please see attached error and audit logs.

...some progress was made on this (but still need help):

1. I found that both my structures Account and Route__c (the custom object created with master-detail relation to Account) weren't correctly setup in the SalesforceConnector.oml module:

• Account was missing the Routes List of Route__c records.

     

• Route__c had an Account Text attribute while it should have been named AccountId, as in the remaining naming conventions

     

2. After some debugging (through auditing inside an extension) I found out that both GetStructureObject() and GetSalesforceFieldNamesFromOutSystemsRecord() methods are not prepared to perform the data type mapping of my Route__c structure. This seems true since even though I was able to bypass the above Object reference... error in GetStructureObject() method (since the mapping was expecting a differently named field which was not what I had for my Route__c structure), I still got a new error from the actual fetching of the item from the Salesforce.com API (see details in attach): INVALID_TYPE: sObject type 'STRoute__cStructure' is not supported. If you are attempting to use a custom object, be sure to append the '__c' after the entity name. Please reference your WSDL or the describe call for the appropriate names.

Any ideas on how to fix this? Is ST[StructureName]Structure an expected .NET Type class value for OutSystems Structures and if so, is Salesforce.com Connector component able to map it correctly?

Hi Pedro,
Seems you were able to troubleshoot it faster than I did :)

Indeed, the problem you're now facing as in fact to do with the fact that this extension will not automatically be able to map child structures. You'll need to keep those structures flat, i.e. leave only the AccountId on the Route structure and exclude the Routes attribute from the Account structure. Then create an action called something like "GetAccountRoutes(AccountId)" that returns a list of routes with AccountId x.

An alternative would be to change the extension to support these non-flat structures, but that would require a lot more complexity (e.g. should the GetAccount always get the full detail of all children? how deep should that be - if the Route object then has its own children, should the call to GetAccount/s also fetch the 2nd level children, etc.)

So I'd say the best route is really to leave you Master structure flat / without the reference to children, and build one action to get all children based on its parentId.

hope this helps