No announcement yet.

Passing attachments via WSDL

  • Filter
  • Time
  • Show
Clear All
new posts

  • Passing attachments via WSDL

    Has anyone ever had the message:
    TypeError: elem has no properties

    Basically I'm passing attachments from SC6 to SM7 and I think there is something more fundamentally wrong but whilst waiting for HP Support I thought I'd try and get a little deeper.

    It seems to have issues serializing, everything gets built up perfectly well. In my custom JS script I call targetService.invoke(<object>)

    Then in my wsdl2js generated JS script it calls function invoke (requestObj, headerObj) okay

    But it seems within that function when it calls lib.SOAP.serialize(this.soapEnvelope, result) I get the error message above.

    If anyone else has come up against this I'd appreciate some advise. It works perfectly well without the attachments build targetService.setAttachments(<my attachment array>). Oh and it works fine going from one SM7environment to another SM7 environment.

    Last edited by Nosnibor35; 2011-03-28, 16:50.

  • #2
    It might be that the WSDL definition from SC6 (as scripted in SM7) isn't OK. Serialization is where it is all put together as a SOAP message (stringed, so to speak) and it builds the output based on the element type definitions in the WSDL in JS.

    Off topic: You on Red Dead soon? My home network is fixed!


    • #3
      Originally posted by harn145 View Post
      It might be that the WSDL definition from SC6 (as scripted in SM7) isn't OK. Serialization is where it is all put together as a SOAP message (stringed, so to speak) and it builds the output based on the element type definitions in the WSDL in JS.

      Off topic: You on Red Dead soon? My home network is fixed!
      Thanks for that mate, it's good to get a better understanding on what's going on. The only problem in this situation is debugging is pretty non-existent even with all the relevant command switches on! It just does not seem to want to connect (when looking at the debughttp log file). I see a difference http version between SC6 and SM7 (like 6 is on 1.0 and 7 is 1.1) but that should make a difference I sure!

      I just don't have enough debug output to analyse the situation any more. HP swear blind that there *shouldn't* be a problem with passing attachments between 6 and 7 but.....

      Off topic: Yes I'll email you about that now


      • #4
        My understanding

        You can do it as blow steps.
        1.Check the AttachmentType attribute, it should contain below attribute list:

        2. Every attribute meaning in WSDL
        href or contentId should be required if you are using SC, but in new version of SM, it could be empty
        href format: "cid:uniqueidentifier", here cid may means contentId, uniqueidentifier is mapped to SYSATTACHMENTS table uid field in dbdict. contentId is the same as href, but use another form only, you can understand as below rule:
        href = "cid:uniqueidentifier"
        contentId = uniqueidentifier
        above two are the same meaning with different form
        action: has four values: add, remove, get, update, it's required when you want to process attachment via WSDL
        name: the file name of the attachment, it's mapped to SYSATTACHMENTS table filename field, you chould set this value by yourself.
        type: this field is different when you use different URLs, for example:
        If you use the endpoint--http://serverHost: Port/sc62server/PWS/extaccessName.wsdl, the type field should be a mime type as "text/plain", but
        if you use the endpoint--http://serverHost: Port/SM/7/extaccessName.wsdl, the type field should not be mime type because it used XTOM/XOP method to process the attachement. We often use the first url to process the attachment although the runtime is SM 7.x or SM 9.x
        len: this is the file size [ Uncompressed size ]
        charset: the encoding for the file data.
        3. The content for the attachment field.
        In SC & SM, the content for the attachment should be the data of base64code format, you should first encode the file bytes firstly, below is an example for these data.
        UmVzdWx0U2V0IHJvdyBjb3VudDo4LCBmaWVsZCBjb3VudDoxNg oJWzhdIGZpZWxkTmFtZToxMTksIGRlZmluZTogWyB0eXBlOnN0 cmluZywgc2l6ZTotMSBdCglbMF0gZmllbGROYW1lOjEyMCwgZG VmaW5lOiBb...
        OKey, how to get these kind of data, in SMJS you should do as below code:
        var source = readFile("C:\\xxx.txt","b");
        var content = base64Encode(source);
        In other language, the objective is the same, you should convert the source data's bytes to base64code format firstly. In fact in soap messages, here I provide a example for the attachment:
        You should set the action attribute in the soap messages.
        4.Please set the high level attribute for attachments on request object.
        Please check the request's attribute attachmentInfo and attachmentData, it should be true if you want to upload attachment via WSDL.
        These attributes doesn't not belong AttachmentType but belong to the type XXXXRequest in HP's web service, for example if there exist a request named CreateIncidentRequest, it should has above two attributes. If you want to upload the attachments via javascript in HP SM & SC, you can write below code:
        Download attachment:
        var service = new lib.IncidentManagement.IncidentManagement();
        var request = new lib.IncidentManagement.RetrieveIncidentRequest();
        request.attachmentInfo = true;
        request.attachmentData = true;
        service.user = "falcon"
        service.pwd = ""
        var response = service.invoke(request);
        // At last you could get the AttachmentType data via below method:
        // response.model.instance.attachments.attachment.length
        // there is no try..catch and if...else, in real business, you need add some definition programming code.
        Upload attachment:
        var service = new lib.IncidentManagement.IncidentManagement();
        var request = new lib.IncidentManagement.CreateIncidentRequest();
        var attachs = new Array();
        var attach = new AttachmentType();
        attach.href = "12345"; // you need not set this in new version such as SM 9.x
        attach.action = "add";
        request.attachmentData = true;
        request.attachmentInfo = true;
        There are 4 key-points:
        1.request's attributes attachmentData and attachmentInfo should be true;
        2.AttachmentType's attribute action should be provided.
        3.The content of attachment should be encoded via base64code method, in SMJS you could use global method base64Encode
        4.The attachments and attachment node use different namespace in soap messages.[Please see above screenshot].
        I hope these information could help you, if there has other response, please contact with me via [email protected]
        Best Regards
        Lang Yu
        Last edited by silentbalanceyh; 2012-05-25, 01:12. Reason: Highline the title


        • #5
          Nice response Lang Yu

          I'll remember that for next time.....


          • #6
            Originally posted by silentbalanceyh View Post
            You can do it as blow steps.

            Best Regards
            Lang Yu
            Massive thanks for this post. I've finally managd to get attachments added thanks to it. If only the official documentation was as clear


            • #7
              We are using HPSC 6.2 and are currently struggling with binary attachments sent via SOAP. Plain text attachments are working fine. Has andybody managed to send binary files (From HPSC to HPSC)?


              • #8
                Turns out sending binary attachments from SC 6.2 is not supported at all due to an internal UTF8<->UTF16 conversion.


                • #9
                  I am trying to accomplish creating incidents with attachments on them via web services using perl SOAP-LITE client (I am interfacing with SM7.11 web API). I cannot seem to get this to work properly. The problem seems to be with the base64 decoding. SM7 seems to only correctly decode parts of my file. Other parts just have gibberish in them (i'm testing with a plain/text document). Has anyone encountered this? I'm not exactly a perl wizard, however I can properly decode this file using perl. It just doesn't seem to work with SM7.11. I feel like I might be missing something simple. Has anyone encountered this? Is there an attribute I need to set somewhere in my code to get this working properly? I tried following all of the steps in this thread, but i'm still running into the problem.