Tracking system don't like XQConstants.CONTENT_TYPE_BYTES - Forum - Technology Partner - Progress Community

Tracking system don't like XQConstants.CONTENT_TYPE_BYTES

 Forum

Tracking system don't like XQConstants.CONTENT_TYPE_BYTES

  • Hello,

    here is the error (I search the KBase, but any trace about) :

    [10/03/23 14:43:41] ID=NodBox (info) [NodBox Service - Decompress Data Instance] Service processing...
    [10/03/23 14:43:41] ID=NodBox (info) [NodBox Service - Decompress Data Instance] Data Part retreived
    [10/03/23 14:43:41] ID=NodBox (info) [NodBox Service - Decompress Data Instance] End of Decrompression
    [10/03/23 14:43:41] ID=NodBox (info) [NodBox Service - Decompress Data Instance] Service processed...
    [10/03/23 14:43:41] ID=NodBox (severe) [Dispatch] Error sending service tracking messages:  (no object DCH for MIME type application: DestinationName=_Tracking (no object DCH for MIME type application))
    [10/03/23 14:43:41] ID=NodBox (severe) [Dispatch] Unable to send tracking message to _Tracking:ENDPOINT
    [10/03/23 14:43:41] ID=NodBox (severe) [Dispatch] Error sending service tracking messages:  (no object DCH for MIME type application: DestinationName=_Tracking (no object DCH for MIME type application))
    [10/03/23 14:43:41] ID=NodBox (info) [NodBox Service - Parse Unzipped Data Instance] Service processing...
    [10/03/23 14:43:41] ID=NodBox (info) [NodBox Service - Parse Unzipped Data Instance] BB3AMessage OK
    [10/03/23 14:43:41] ID=NodBox (info) [NodBox Service - Parse Unzipped Data Instance] getBB3A_ID :: abcd1234
    [10/03/23 14:43:41] ID=NodBox (info) [NodBox Service - Parse Unzipped Data Instance] getFileId :: file1
    [10/03/23 14:43:41] ID=NodBox (info) [NodBox Service - Parse Unzipped Data Instance] Service processed...

    Ther is not a error on the process, the process end's OK, is a tracking error.

    The tracking system stops after this error and we can't got any trace.

    here is the code in a "Java Custom Service"

                // Add Object as new Part
                XQPart aPart = message.createPart();
                aPart.setContentId("object");
                aPart.setContent(myObject, XQConstants.CONTENT_TYPE_BYTES);
                message.addPart(aPart);

    any help aprecieted, thank's

    Rares Stanciulescu

  • What is the Java type of myObject? is it a byte[]? if not ESB will try convert it to a byte[] using a data content handler based on the mime type. But the mime type says it already is a byte[]. So it gives up.

    Thomas

  • MyObject is a java serializable object (class with private members; setters and getters) used to store message and session informations.

    The idea is to transfer to next custom service an object.

    If the problem is due to the XQConstants.CONTENT_TYPE_BYTES, what is the type to use if you want to transfert an object?

  • It is not so much about the content type.

    Data Content Handlers serialization (what the multipart messages tries to use) and serializable objects serialization have nothing in common.

    So what you need to to is to serialize it yourself to a byte[] and store that as part content.

    Alternatively, the part content can be an JMS ObjectMessage (progress.jclient*) and that would serialize it for you.

    Either way.

    Thomas

  • I am facing this kind of problem when I try to create a binary part from a pdf file.

    Ihave also tried to use a ByteArrayDataSource but I get the same output.

    contentDownload is a byte[]

    Code :

    partDl =msg.createPart();

    partDl.setDataHandler(new DataHandler(new ByteArrayDataSource(this.contentDownload, "application/pdf"))); // replacing "application/pdf by  XQConstants.CONTENT_TYPE_BYTES don't work too.

    // I get a similar error if I use :

    partDl.setContent(this.contentDownload; XQConstants.CONTENT_TYPE_BYTES);

    msg.addPart(partDl);
    ctx.addOutgoing(msg);

    here is the error trace

    [10/03/26 17:56:11] ID=dev_ESBTest (info) [Dispatch] Message Rejected, rejected message could not be created for XQDispatcher for application FTPConnector

    [10/03/26 17:56:11] ID=dev_ESBTest (info) [Dispatch] Cause of rejected message: XQ_ENDPOINT_EXCEPTION

    [10/03/26 17:56:11] ID=dev_ESBTest (info) Trace follows...
    com.sonicsw.xq.XQEndpointException: no object DCH for MIME type application/pdf: DestinationName=MgmtBroker::$ISYS.USERS.TemporaryTopicsAdministrator$TMPAPPID$147$$CONNECTION$.582971472 (no object DCH for MIME type application/pdf) (no object DCH for MIME type application/pdf)
        at com.sonicsw.xq.connector.jms.JMSEndpoint$EndpointConnection.sendWithUnbound(JMSEndpoint.java:1621)

    regards

    Chan Jeremy

  • Jeremy,

    can you attach the full code so we can reproduce it?

    Also, do you have the full stack (e.g. including any caused by)?

    Thomas

  • Sorry for the late answer Thomas.

    I had missed something in an other service when I ran my test (with contentType as byte) .

    Using bytearraydatasource to construct an XQmessage seems not to be a good way.

    Thanks

    Chan Jeremy

  • I think I'm encountering the same or similar issue as the original poster.  I have a set of member objects that need to be asynchronously dispatched as independent messages, each message containing one member - fire and forget fashion.  When I either disable intra-container messaging to achieve the asynchronous behavior or dispatch to the destination endpoint name vs the destination process name, there are serialization errors and I get an XQDispatchException driven by an XQEndpointException:

    XQEndpointException (no object DCH for MIME type application/octet-stream: DestinationName=C2CRequestForResourceForwardedRequestService.Entry (no object DCH for MIME type application/octet-stream)) (no object DCH for MIME type application/octet-stream: DestinationName=C2CRequestForResourceForwardedRequestService.Entry (no object DCH for MIME type application/octet-stream) (no object DCH for MIME type application/octet-stream))

    There doesn't appear to be an XQConstants value which will treat the part as a general object for an ObjectMessage type and leave the implementor to cast it properly in the destination process/service.  Is this correct?

    Even if I use the XQServiceContext.getMessageFactory().createMessage() to create a JMS Message flavor, when I add my object part content, I will still have to specify some string value that maps to a DataContentHandler.  You mentioned a progress.message.jclient.ObjectMessage type.  How do we specify this?

    Thanks.

  • I did this before the dispatch of myObject type:


                    byte[] bArray = null ;
                    ObjectOutputStream out = null ;
                    try {
                        ByteArrayOutputStream b = new ByteArrayOutputStream() ;
                        out = new ObjectOutputStream( b ) ;
                        out.writeObject( myObject ) ;       
                        bArray = b.toByteArray() ;
                    } catch (Exception e) {
                        log.error( "Exception processing myObject", e ) ;
                    } finally {
                            try { if (out != null) out.close() ; } catch ( IOException e ) {}       
                    }

    then you can create a new message, add myObject, and use the XQConstants.CONTENT_TYPE_BYTES.

    On the receiving end, it needs to be deserialized from the byte[] type and cast to myObject type:


            ByteArrayInputStream in = null ;
            ObjectInputStream oi = null ;
            try {
                in = new ByteArrayInputStream( (byte[]) this.getObject( a_XQEnvelope ) ) ;
                oi = new ObjectInputStream( in ) ;
                myObject myObj = (myObject) oi.readObject() ;
               
            } catch ( XQMessageException xqme ) {
                log.error( "Exception processing forwarded R2I2 originating request", xqme ) ;
            } catch ( Exception e ) {
                log.error( "Exception processing forwarded R2I2 originating request", e ) ;
            } finally {
                try { if (oi != null) oi.close() ; } catch ( IOException e ) {}       
            }


    The ObjectOutputStream and ObjectInputStream objects do need to be deliberately closed in the finally block so that the resources are made available.  The API states this explicitly.

    Wrapping this serialization and deserialization into an ObjectUtils class for quick re-use, get can do something really simple in custom services with send and receive to get:

    ObjectUtils.toBytes( Object a_object ) and

    ObjectUtils.toObject( byte[] a_bytes )