• Haris Osmanagic, B&H
  • NEWBIE
  • 0 Points
  • Member since 2014

  • Chatter
    Feed
  • 0
    Best Answers
  • 1
    Likes Received
  • 0
    Likes Given
  • 5
    Questions
  • 8
    Replies
Hi all,

The situation is as follows:

In my Salesforce org, I have a contact, let's call it Humpty Dumpty, and I'd like to attach a file to it, let's call it cooking.txt, but there are some rules:

If there attachment is already there, overwrite it.
If the attachment isn't there, attach it.

For that purpose, I'm using Bulk API and upserts.

request.txt looks like below:<?xml version="1.0" encoding="UTF-8"?> <sObjects xmlns="http://www.force.com/2009/06/asyncapi/dataload" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <sObject> <ContentType>text/plain</ContentType> <Description/> <Name>cooking.txt</Name> <Body>#cooking.txt</Body> <Id>00P_blah_blah</Id> <ParentId>003_blah_blah</ParentId> </sObject> </sObjects>00P_blah_blah is the ID of the attachment attached to my contact, Humpty Dumpty. My intention is to use it as the external ID field in upsert, so that, if an attachment with that ID already exists, it'll be updated, and if not, it'll be inserted.

In my Java code, I also do this:job.setOperation(OperationEnum.upsert); job.setExternalIdFieldName("Id");where job is an instance of JobInfo.

However, this fails, and the error is:Errors(fields=null, message=invalid record id, statusCode=INVALID_ID_FIELD)Anyone knows what could be the reason for this, and how to fix it?

Thanks all!
I'm using the code below to create a feed element with an attachment, using Chatter REST API, v32.0.

        File feedElementDefinition = new File("feed3.txt");
        String json = IOUtils.toString(new FileInputStream(feedElementDefinition));

        CloseableHttpClient client = HttpClients.createDefault();
        HttpPost post = new HttpPost(
            "https://eu3.salesforce.com/services/data/v32.0/chatter/feed-elements" +
            "?feedElementType=FeedItem" +
            "&subjectId=<id of my user account>" +
            "&text=Text"
        );
        post.addHeader(HttpHeaders.AUTHORIZATION, token());
        post.addHeader(HttpHeaders.CONTENT_TYPE, ContentType.MULTIPART_FORM_DATA.getMimeType());
        post.addHeader(HttpHeaders.ACCEPT, ContentType.WILDCARD.getMimeType());
        post.setEntity(
            MultipartEntityBuilder.create()
                .addBinaryBody(
                    "feedElementFileUpload",
                    new File("feed_element.txt"),
                    ContentType.APPLICATION_OCTET_STREAM,
                    "feed_element.txt"
                )
                .addTextBody(
                    "json",
                    json,
                    ContentType.APPLICATION_JSON
                ).build()
        );
        CloseableHttpResponse response = client.execute(post);

Contents of `feed3.txt` are:

    {
      "body" : {
        "messageSegments" : [ {
          "text" : "Some dummy status",
          "type" : "Text"
        } ]
      },
      "capabilities" : {
        "associatedActions" : null,
        "bookmarks" : {
          "isBookmarkedByCurrentUser" : false
        },
        "content" : {
          "description" : "feed_file",
          "title" : "feed3.txt"
        }
      },  
      "feedElementType" : "FeedItem",
      "originalFeedElementId" : null,
      "visibility" : "AllUsers",
      "subjectId" : "<my user account id>"
    }

However, it fails with the following message:

    You have sent us an Illegal URL or an improperly formatted request.

What's the reason for this? I'm going almost crazy on this one, since when I use cURL (show below), it's fine.

    curl -H "X-PrettyPrint: 1" -H "Content-Type: multipart/form-data" -F 'json={ "body" : { "messageSegments" : [ { "text" : "Some dummy status", "type" : "Text" } ] }, "capabilities" : { "associatedActions" : null, "bookmarks" : { "isBookmarkedByCurrentUser" : false }, "content" : { "description" : "feed_file", "title" : "feed3" } },  "feedElementType" : "FeedItem", "originalFeedElementId" : null, "visibility" : "AllUsers", "subjectId" : "my_user_account_id" };type=application/json' -F "feedElementFileUpload=@/home/haris/projects/open-source/java-playground/feed3.txt;type=application/octet-stream" 
    -X POST 'https://eu3.salesforce.com/services/data/v32.0/chatter/feed-elements?feedElementType=FeedItem&subjectId=my_user_account_id&text=Text' -H 'Authorization: OAuth my_token_blah_blah' --insecure

Thanks in advance!
I am trying to get a list of all metadata objects with the given name. However, the code (in Java) below fails:

connection.readMetadata("ApexClass", new String[] {"SampleDeployClass"});
with this error:
Exception in thread "main" com.sforce.ws.SoapFaultException: INVALID_TYPE: This type of metadata is not available for this organization

Using connection.listMetadata() I am able to confirm that SampleDeployClass exists. I'm using a DE org, and the user has the Modify all data permission.

Is this something expexted (couldn't find it in the docs)? If yes, how am I able to confirm that a set of metadata objects already exists (other than retrieve() (https://www.salesforce.com/us/developer/docs/api_meta/Content/meta_retrieve.htm))?

Seems like renameMetadata() (https://www.salesforce.com/us/developer/docs/api_meta/Content/meta_renameMetadata.htm) doesn't work with ApexClasses either. Is it maybe a restriction in the API which prevents anyone from changing Apex code?
Hi all,

I'm evaluating pros and cons for building an integration with Salesforce on Force.com platform. Since the pros don't need to be commented on, I'll just ask about what some developers consider as cons. I came across this SO question: http://stackoverflow.com/questions/1664503/disadvantages-of-the-force-com-platform What part of this can you confirm as true, and what not? The question is closed because of the format, but it'd be great if someone could provide concrete answers to it (when you google for disadvantages you get this at the top). I'll copy and paste some of the mentioned disadvantages for easier referencing:
  1. Apex is a proprietary language. Other than the foce.com Eclipse plugin, there's little to no tooling available such as refactoring, code analysis, etc.
  2. Apex was modeled on Java 5, which is considered to be lagging behind other languages, and without tooling (see #1), can be quite cumbersome.
  3. Deployment is still fairly manual with lots of gotchas and manual steps. This situation is slowly improving over time, but you'll be disappointed if you're used to having automated deployments.
  4. Apex lacks packages/namespaces. All of your classes, interfaces, etc. live in one folder on the server. This makes code much less organized and class/interface names necessarily long to avoid name clashes and to provide context. This is one of my biggest complaints, and I would not freely choose to build on force.com for this reason alone.
  5. The "force.com IDE", aka force.com eclipse plugin, is incredibly slow. Saving any file, whether it be a class file, text file, etc., usually takes at least 5 seconds and sometimes up to 30 seconds depending on how many objects, data types, class files, etc. are in your org. Saving is also a blocking action, requiring not only compilation, but a full sync of your local project with the server. Orders of magnitude slower than Java or .NET.
  6. The online developer community does not seem very healthy. I've noticed lots of forum posts go unanswered or unsolved. I think this may have something to do with the forum software salesforce.com uses, which seems to suck pretty hard.
  7. The data access DSL in Apex leaves a lot to be desired. It's not even remotely competitive with the likes of (N)Hibernate, JPA, etc.
  8. Developing an app on Apex/VisualForce is an exercise in governor limits engineering. Easily half of programmer time is spent trying to optimize to avoid the numerous governor limits and other gotchas like visualforce view state limits. It could be argued that if you write efficient code to begin with you won't have this problem, which is true to an extent. However there are many times that you have valid reasons to make more than x queries in a session, or loop through more than x records, etc.
  9. The save->compile->run cycle is extremely slow, esp. when it involves zipping and uploading the entire static resource bundle just to do something like test a minor css or javascript change.
  10. In general, the pain of a young, fledgling platform without the benefits of it being open source. You have no way to validate and/or fix bugs in the platform. They say to post it to their IdeaExchange. Yeah, good luck with that.
  11. You can't package up your app and deliver it to users without significant user intervention and configuration on the part of the administrator of the org.
  12. THERE IS NO DEBUGGER! If you want to debug, it's literally debug by system.debug statements. This is probably the biggest problem I've found
  13. Even tho the language is java based, it's not java. You can't import any external packages or libraries. Also the base libraries that are available are severely limited so we've found ourselves implementing a bunch of stuff externally and then exposing those bits as services that are called by force.com
  14. There is no mention anywhere in even the most deep-dark technical references of the common errors, or even the limitations of a given api or feature

Hi all,

What are the pros and cons of
* developing an application integration with Salesforce using Force.com platform (packages), and
* developing it (in Java) using SF's SOAP/REST/etc. API.

The points I'm especially interested are:
* dev. experience (availability of support, tools, etc.)
* user experience (installation, permission stuff etc.)
* limits (in the sense of manipulating an organization's data, or in other words: is there something which can be done with an org's data using Force.com platform that can't be done using it's SOAP/REST/etc. APIs?)

(I'm a Salesforce newbie, so I may haved missed the right terminology at some points.)

Thanks in advance!

Haris
Hi all,

I'm evaluating pros and cons for building an integration with Salesforce on Force.com platform. Since the pros don't need to be commented on, I'll just ask about what some developers consider as cons. I came across this SO question: http://stackoverflow.com/questions/1664503/disadvantages-of-the-force-com-platform What part of this can you confirm as true, and what not? The question is closed because of the format, but it'd be great if someone could provide concrete answers to it (when you google for disadvantages you get this at the top). I'll copy and paste some of the mentioned disadvantages for easier referencing:
  1. Apex is a proprietary language. Other than the foce.com Eclipse plugin, there's little to no tooling available such as refactoring, code analysis, etc.
  2. Apex was modeled on Java 5, which is considered to be lagging behind other languages, and without tooling (see #1), can be quite cumbersome.
  3. Deployment is still fairly manual with lots of gotchas and manual steps. This situation is slowly improving over time, but you'll be disappointed if you're used to having automated deployments.
  4. Apex lacks packages/namespaces. All of your classes, interfaces, etc. live in one folder on the server. This makes code much less organized and class/interface names necessarily long to avoid name clashes and to provide context. This is one of my biggest complaints, and I would not freely choose to build on force.com for this reason alone.
  5. The "force.com IDE", aka force.com eclipse plugin, is incredibly slow. Saving any file, whether it be a class file, text file, etc., usually takes at least 5 seconds and sometimes up to 30 seconds depending on how many objects, data types, class files, etc. are in your org. Saving is also a blocking action, requiring not only compilation, but a full sync of your local project with the server. Orders of magnitude slower than Java or .NET.
  6. The online developer community does not seem very healthy. I've noticed lots of forum posts go unanswered or unsolved. I think this may have something to do with the forum software salesforce.com uses, which seems to suck pretty hard.
  7. The data access DSL in Apex leaves a lot to be desired. It's not even remotely competitive with the likes of (N)Hibernate, JPA, etc.
  8. Developing an app on Apex/VisualForce is an exercise in governor limits engineering. Easily half of programmer time is spent trying to optimize to avoid the numerous governor limits and other gotchas like visualforce view state limits. It could be argued that if you write efficient code to begin with you won't have this problem, which is true to an extent. However there are many times that you have valid reasons to make more than x queries in a session, or loop through more than x records, etc.
  9. The save->compile->run cycle is extremely slow, esp. when it involves zipping and uploading the entire static resource bundle just to do something like test a minor css or javascript change.
  10. In general, the pain of a young, fledgling platform without the benefits of it being open source. You have no way to validate and/or fix bugs in the platform. They say to post it to their IdeaExchange. Yeah, good luck with that.
  11. You can't package up your app and deliver it to users without significant user intervention and configuration on the part of the administrator of the org.
  12. THERE IS NO DEBUGGER! If you want to debug, it's literally debug by system.debug statements. This is probably the biggest problem I've found
  13. Even tho the language is java based, it's not java. You can't import any external packages or libraries. Also the base libraries that are available are severely limited so we've found ourselves implementing a bunch of stuff externally and then exposing those bits as services that are called by force.com
  14. There is no mention anywhere in even the most deep-dark technical references of the common errors, or even the limitations of a given api or feature

Hi all,

The situation is as follows:

In my Salesforce org, I have a contact, let's call it Humpty Dumpty, and I'd like to attach a file to it, let's call it cooking.txt, but there are some rules:

If there attachment is already there, overwrite it.
If the attachment isn't there, attach it.

For that purpose, I'm using Bulk API and upserts.

request.txt looks like below:<?xml version="1.0" encoding="UTF-8"?> <sObjects xmlns="http://www.force.com/2009/06/asyncapi/dataload" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <sObject> <ContentType>text/plain</ContentType> <Description/> <Name>cooking.txt</Name> <Body>#cooking.txt</Body> <Id>00P_blah_blah</Id> <ParentId>003_blah_blah</ParentId> </sObject> </sObjects>00P_blah_blah is the ID of the attachment attached to my contact, Humpty Dumpty. My intention is to use it as the external ID field in upsert, so that, if an attachment with that ID already exists, it'll be updated, and if not, it'll be inserted.

In my Java code, I also do this:job.setOperation(OperationEnum.upsert); job.setExternalIdFieldName("Id");where job is an instance of JobInfo.

However, this fails, and the error is:Errors(fields=null, message=invalid record id, statusCode=INVALID_ID_FIELD)Anyone knows what could be the reason for this, and how to fix it?

Thanks all!
I'm using the code below to create a feed element with an attachment, using Chatter REST API, v32.0.

        File feedElementDefinition = new File("feed3.txt");
        String json = IOUtils.toString(new FileInputStream(feedElementDefinition));

        CloseableHttpClient client = HttpClients.createDefault();
        HttpPost post = new HttpPost(
            "https://eu3.salesforce.com/services/data/v32.0/chatter/feed-elements" +
            "?feedElementType=FeedItem" +
            "&subjectId=<id of my user account>" +
            "&text=Text"
        );
        post.addHeader(HttpHeaders.AUTHORIZATION, token());
        post.addHeader(HttpHeaders.CONTENT_TYPE, ContentType.MULTIPART_FORM_DATA.getMimeType());
        post.addHeader(HttpHeaders.ACCEPT, ContentType.WILDCARD.getMimeType());
        post.setEntity(
            MultipartEntityBuilder.create()
                .addBinaryBody(
                    "feedElementFileUpload",
                    new File("feed_element.txt"),
                    ContentType.APPLICATION_OCTET_STREAM,
                    "feed_element.txt"
                )
                .addTextBody(
                    "json",
                    json,
                    ContentType.APPLICATION_JSON
                ).build()
        );
        CloseableHttpResponse response = client.execute(post);

Contents of `feed3.txt` are:

    {
      "body" : {
        "messageSegments" : [ {
          "text" : "Some dummy status",
          "type" : "Text"
        } ]
      },
      "capabilities" : {
        "associatedActions" : null,
        "bookmarks" : {
          "isBookmarkedByCurrentUser" : false
        },
        "content" : {
          "description" : "feed_file",
          "title" : "feed3.txt"
        }
      },  
      "feedElementType" : "FeedItem",
      "originalFeedElementId" : null,
      "visibility" : "AllUsers",
      "subjectId" : "<my user account id>"
    }

However, it fails with the following message:

    You have sent us an Illegal URL or an improperly formatted request.

What's the reason for this? I'm going almost crazy on this one, since when I use cURL (show below), it's fine.

    curl -H "X-PrettyPrint: 1" -H "Content-Type: multipart/form-data" -F 'json={ "body" : { "messageSegments" : [ { "text" : "Some dummy status", "type" : "Text" } ] }, "capabilities" : { "associatedActions" : null, "bookmarks" : { "isBookmarkedByCurrentUser" : false }, "content" : { "description" : "feed_file", "title" : "feed3" } },  "feedElementType" : "FeedItem", "originalFeedElementId" : null, "visibility" : "AllUsers", "subjectId" : "my_user_account_id" };type=application/json' -F "feedElementFileUpload=@/home/haris/projects/open-source/java-playground/feed3.txt;type=application/octet-stream" 
    -X POST 'https://eu3.salesforce.com/services/data/v32.0/chatter/feed-elements?feedElementType=FeedItem&subjectId=my_user_account_id&text=Text' -H 'Authorization: OAuth my_token_blah_blah' --insecure

Thanks in advance!
I am trying to get a list of all metadata objects with the given name. However, the code (in Java) below fails:

connection.readMetadata("ApexClass", new String[] {"SampleDeployClass"});
with this error:
Exception in thread "main" com.sforce.ws.SoapFaultException: INVALID_TYPE: This type of metadata is not available for this organization

Using connection.listMetadata() I am able to confirm that SampleDeployClass exists. I'm using a DE org, and the user has the Modify all data permission.

Is this something expexted (couldn't find it in the docs)? If yes, how am I able to confirm that a set of metadata objects already exists (other than retrieve() (https://www.salesforce.com/us/developer/docs/api_meta/Content/meta_retrieve.htm))?

Seems like renameMetadata() (https://www.salesforce.com/us/developer/docs/api_meta/Content/meta_renameMetadata.htm) doesn't work with ApexClasses either. Is it maybe a restriction in the API which prevents anyone from changing Apex code?
Hi all,

I'm evaluating pros and cons for building an integration with Salesforce on Force.com platform. Since the pros don't need to be commented on, I'll just ask about what some developers consider as cons. I came across this SO question: http://stackoverflow.com/questions/1664503/disadvantages-of-the-force-com-platform What part of this can you confirm as true, and what not? The question is closed because of the format, but it'd be great if someone could provide concrete answers to it (when you google for disadvantages you get this at the top). I'll copy and paste some of the mentioned disadvantages for easier referencing:
  1. Apex is a proprietary language. Other than the foce.com Eclipse plugin, there's little to no tooling available such as refactoring, code analysis, etc.
  2. Apex was modeled on Java 5, which is considered to be lagging behind other languages, and without tooling (see #1), can be quite cumbersome.
  3. Deployment is still fairly manual with lots of gotchas and manual steps. This situation is slowly improving over time, but you'll be disappointed if you're used to having automated deployments.
  4. Apex lacks packages/namespaces. All of your classes, interfaces, etc. live in one folder on the server. This makes code much less organized and class/interface names necessarily long to avoid name clashes and to provide context. This is one of my biggest complaints, and I would not freely choose to build on force.com for this reason alone.
  5. The "force.com IDE", aka force.com eclipse plugin, is incredibly slow. Saving any file, whether it be a class file, text file, etc., usually takes at least 5 seconds and sometimes up to 30 seconds depending on how many objects, data types, class files, etc. are in your org. Saving is also a blocking action, requiring not only compilation, but a full sync of your local project with the server. Orders of magnitude slower than Java or .NET.
  6. The online developer community does not seem very healthy. I've noticed lots of forum posts go unanswered or unsolved. I think this may have something to do with the forum software salesforce.com uses, which seems to suck pretty hard.
  7. The data access DSL in Apex leaves a lot to be desired. It's not even remotely competitive with the likes of (N)Hibernate, JPA, etc.
  8. Developing an app on Apex/VisualForce is an exercise in governor limits engineering. Easily half of programmer time is spent trying to optimize to avoid the numerous governor limits and other gotchas like visualforce view state limits. It could be argued that if you write efficient code to begin with you won't have this problem, which is true to an extent. However there are many times that you have valid reasons to make more than x queries in a session, or loop through more than x records, etc.
  9. The save->compile->run cycle is extremely slow, esp. when it involves zipping and uploading the entire static resource bundle just to do something like test a minor css or javascript change.
  10. In general, the pain of a young, fledgling platform without the benefits of it being open source. You have no way to validate and/or fix bugs in the platform. They say to post it to their IdeaExchange. Yeah, good luck with that.
  11. You can't package up your app and deliver it to users without significant user intervention and configuration on the part of the administrator of the org.
  12. THERE IS NO DEBUGGER! If you want to debug, it's literally debug by system.debug statements. This is probably the biggest problem I've found
  13. Even tho the language is java based, it's not java. You can't import any external packages or libraries. Also the base libraries that are available are severely limited so we've found ourselves implementing a bunch of stuff externally and then exposing those bits as services that are called by force.com
  14. There is no mention anywhere in even the most deep-dark technical references of the common errors, or even the limitations of a given api or feature

Hi all,

What are the pros and cons of
* developing an application integration with Salesforce using Force.com platform (packages), and
* developing it (in Java) using SF's SOAP/REST/etc. API.

The points I'm especially interested are:
* dev. experience (availability of support, tools, etc.)
* user experience (installation, permission stuff etc.)
* limits (in the sense of manipulating an organization's data, or in other words: is there something which can be done with an org's data using Force.com platform that can't be done using it's SOAP/REST/etc. APIs?)

(I'm a Salesforce newbie, so I may haved missed the right terminology at some points.)

Thanks in advance!

Haris

I am using Java with the SOAP api to transfer Chatter records.  I cannot post messages to existing Chatter groups.

 

The code below is simple Java code that tries to create a new FeedItem, add it to a group and insert the record.  I have confirmed that the userID is correct, the groupId is correct AND the user belongs to the group.  The user account I am using to do the transfer has the "Manage Chatter Messages" enabled.  I am using API v 25.

 

Why is my attempt to post to a group failing?

 

The error message I get is: The Insert failed because: insufficient access rights on cross-reference id

 

		String userID = "005E0000001JywAIAS";
		String groupId = "0F9E0000000Tp2mKAC";
		FeedItem newFeed = new FeedItem();
		Calendar greg = Calendar.getInstance();
		greg.add(Calendar.HOUR, -48);
		
		//newFeed.setId(feed.getId());
		newFeed.setBody("Faked ITEM GROUP test");
		newFeed.setParentId(groupId);
		newFeed.setCreatedDate(greg);
		newFeed.setCreatedById(userID);
		
		List<FeedItem> list = new ArrayList<FeedItem>();
		list.add(newFeed);
		loginCentral();
		SObject[] objs = new SObject[1];
		objs[0]=newFeed;
		uploadRecords(objs);

		logout();

 

  • September 08, 2012
  • Like
  • 0

Hi Guys.

 

I am using the data loader command line to copy data from external system to salesforce.

 

I have two objects in salesforce, as well as external system, media and attachement.  media is parent, attachment is child.

 

In the attachment mapping file, the relationship item is 

 

Media__c\:Parent\:ExternalID__c 

 

so that the attachment could  be inserted with the relationship of media. 

 

But I got error message 

 

mapping is invalid: MediaId => Media__c:Parent:Ext
ernalID__c

 

I also tried Parent\:ExternalID__c as well, got similar error message. 

 

Note: I have uploaded the Media data with extenal Id successfully. 

 

How should I specify the mappings?

 

Thanks in advance.