Iam using Websphere MQ V8.
I need to get the filename from the header in incoming message file. Is there any properties or default methods available to get it.
Sample File:
The file ame you show in the non-hex dump of your message was put there by the sending application. You should ask the sending application how it was put in there, so that you can know how to pull it out.
Alternatively, show the hex version of your message as well and we might be able to help you further. All the important stuff is not visible to us in your screen shot.
That looks like an RFH version 1 header (not RFH2) but as Morag said, we need to see a hex dump of the message. There are lots of tools to see the hex dump of the message. i.e. amqsbcg, MO71, MQ Visual Edit, etc...
From the manual:
The RFH header guidelines only allow for a single header to exist in a message. The fixed binary set of properties is followed by a variable set of name/value pairs.
strucid
version
struclength
encoding
codedcharsetid
format
flags
namevaluestring
The filename is in the "namevaluestring" section and as Morag said, you need to have a discussion with the sending application to understand the format they used.
Finally, if this is a new sending application being developed then tell the developer to NOT use RFH version 1 but rather message properties.
Related
I try to build an xml message to inject it in IBM MQ.
The format to be used should be RFH2. Do you know, do you have any documentation about the format (xsd?) of the header?
Thank you.
MQ's RFH2 is an extensible header consisting of a fixed-format binary structure followed by a variable portion with an XML-like syntax.
The structure is described (in basic terms) in the Knowledge Center here:
https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_9.1.0/com.ibm.mq.ref.dev.doc/q099070_.htm
Some MQ clients (for example JMS and .NET) will automatically prefix the messages they send with an RFH2 header. If you are using one of these clients then you might not need to encode the RFH2 yourself - it will be added for you.
Do you have any more information about why the application needs an RFH2 header?
The RFH2 is often used to carry message properties so you will need to ensure that you encoded these correctly if you are building your own RFH2.
If the application is using the MQ JMS or .NET client then it will be expecting the RFH2 header in the message to be formatted as described in the following topic:
https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_9.1.0/com.ibm.mq.dev.doc/q032000_.htm
You may find the following utility program (rfhutil) helpful in understanding the RFH2 header and debugging your application:
https://github.com/ibm-messaging/mq-rfhutil
Note that the variable portion of the RFH2 header uses an XML-like syntax but does not support or understand all the features of XML, so you should not attempt to include your XML payload in the variable portion of the RFH2 header.... Instead the XML document should follow the RFH2 in the message.
One last point to note is that MQ can perform codepage conversions based on the format and CCSID of the message, but this is rarely what you want with an XML document (which typically describes the character encoding of the document it's own declaration like this: <?xml version="1.0" encoding="UTF-8" standalone="no" ?>. I would therefore recommend that you set the Format field in the RFH2 to "MQFMT_NONE" so that the XML document is treated as binary data and not converted unnecessarily when the message is received by the MQ client.
I'm trying to define a few custom Event Viewer events. I've been following the instructions in MSDN and few other online sources, yet the event viewer can't find the associated text data.
This is what I've done:
Created an input file for the message compiler with the event codes and relevant strings (following the WDK Serial driver example).
Included the .rc file generated by the message compiler in the main driver resource file (MyDriver.rc).
Included the header file generated by the message compiler in the relevant driver module.
Used the NdisWriteErrorLogEntry API to write events with new ids from the included header file.
Added the driver binary to the Inf registry string identifying the event sources:
HKR, , EventMessageFile, 0x00020000, "%%SystemRoot%%\System32\netevent.dll; %%SystemRoot%%\System32\drivers\MyDriver.sys"
HKR, , TypesSupported, 0x00010001, 7
Everything works, except for strings display by the event viewer. It doesn't seem to recognize them and displays "the message resource is present but the message is not found in the string/message table" in the event description.
The only significant difference from the WDK example is the usage of NDIS API instead of the generic WDM API.
I'm also pretty confident that the text is included in the driver binary, since when opening the .sys file with editor I clearly see my strings there.
Would appreciate any suggestions on this issue.
Well, after a year and a half I found the problem. Apparently, the event viewer registry string parser is unable to properly extract the second messages file name if there is a whitespace before it.
Thus, in order to fix it, all is needed is remove the whitespace. I.e., instead of:
HKR, , EventMessageFile, 0x00020000, "%%SystemRoot%%\System32\netevent.dll; %%SystemRoot%%\System32\drivers\MyDriver.sys"
Write this in the inf file:
HKR, , EventMessageFile, 0x00020000, "%%SystemRoot%%\System32\netevent.dll;%%SystemRoot%%\System32\drivers\MyDriver.sys"
I've set up a gmail account to use when sending email notifications from my TeamCity installation. The emails are being sent correctly, but I want to specify the From: header using their .ftl files. According to this page (under Supported Output Values), I can specify email headers. I've copied their <global#... block directly into a number of their template files, namely common.ftl, build_successful.ftl and it never works.
The block I added looks like this:
<#global headers>
From: Some Test <myteamcitytestnotreal#gmail.com>
</#global>
It doesn't do anything. Neither does their sample headers. Any help is appreciated.
You can specify the From: address via the UI under Administration > Email Notifier -> Send email messages from:.
This updates the value stored in the <TeamCity data directory>/config/_notifications/email/email-config.xml file.
I suspect overriding the From: address at the ftl template level is not a supported approach given that the above is the documented method; it might make for a good feature request in TC 9.0.
My company runs a 4GL application internally. It's very old and no one really knows how to improve/develop for it since the developers are long gone.
I need to make a simple SOAP call to my Magento web store. There are tons of examples online in a multitude of languages, but I can't find a single 4GL (OpenEdege ABL) example.
I'm trying to set SKU's to Out of stock status.
Does anyone have a simple example that I can look at, or at least a starting point since there seems to be so little information on 4GL on the web.
Example of the call I need in PHP:
<?php
$proxy = new SoapClient('http://www.domain.com/api/soap/?wsdl');
$sessionId = $proxy->login('admin', 'password');
$proxy->call($sessionId, 'product_stock.update', array('sku123', array('qty'=>50, 'is_in_stock'=>1)));
For version 10.2B there's built in support for consuming web services in Progress ABL.
This is a basic tutorial of how to create a client for a SOAP-based web service in ABL. It's not best practices or in any way complete. Just a quick guide to get started.
1. Analyse the WSDL
There's a built in tool available via command line that lets you analyse a WSDL and create documentation about available services, datatypes, syntax etc. Invoke it on your wsdl like this:
proenv> bprowsdldoc yourwsdl-file c:\temp\docs
The wsdl can be local or remote. If its remote you specify the URL, if it's local you can specify just the local complete path. Documentation in html format will end up in c:\temp\docs. Open up index.html in that folder.
2. Create a basic client
In the index.html document there's a number of headings. Click the link under "Port types". In the Port Type document you will find some useful data.
Copy-and-paste the example in "Connection Details" into your Progress Editor. It should look something like this (names of services and procedures will be different - they are defined in the wsdl):
DEFINE VARIABLE hWebService AS HANDLE NO-UNDO.
DEFINE VARIABLE hYYY AS HANDLE NO-UNDO.
CREATE SERVER hWebService.
hWebService:CONNECT("-WSDL 'file_or_url_to_wsdl.wsdl'").
RUN XXX SET hYYY ON hWebService.
If you run this code your client is connected to the web service but it's still not doing anything.
Further down the same document there's a heading called "Operation (internal procedure) details". This is where the actual web service is invoked. It will look something like the code below. It actually show two ways of making the same call, one functional call and one procedural so choose whatever you prefer and insert it into your editor (I'm usually using the procedural for no real reason other than old habits):
DEFINE VARIABLE strXMLRequest AS CHARACTER NO-UNDO.
DEFINE VARIABLE ProcessXMLResult AS CHARACTER NO-UNDO.
FUNCTION ProcessXML RETURNS CHARACTER
(INPUT strXMLRequest AS CHARACTER)
IN hYYY.
/* Function invocation of ProcessXML operation. */
ProcessXMLResult = ProcessXML(strXMLRequest).
/* Procedure invocation of ProcessXML operation. */
RUN ProcessXML IN hYYY (INPUT strXMLRequest, OUTPUT ProcessXMLResult).
Now all you need to end your program is disconnecting and cleaning up. So insert:
hWebService:DISCONNECT().
DELETE OBJECT hWebService.
If you've followed all steps you should have a skeleton for invoking a web service. The only problem is that you need to handle the in- and out-data.
3. Handle the answer and the request
Depending on how the web service is built this can be easy (if you only input and output simple data like strings and numbers) or quite complicated (if you input and output entire xml-documents). The documentation you created in step one lists all datatypes (in the index.html document) but it doesn't offer any support in how you create any needed xml documents. There's specific Progress documentation available on how to work with xml...
The better approach is to take a look at the official documentation. There you will find everything above and more - how to handle errors etc.
Here is an overview of all 10.2B documentation and here is the PDF named Web Services.
Here is a link to a complete (but actually not so good) example in the Progress KnowledgeBase where a client and corresponding request/response xml is created and handled.
Look at these chapters:
6 - Creating an ABL Client from WSDL
7 - Connecting to Web Services from ABL
8 - Invoking Web Service Operations from ABL
That will basically take you through the entire process from start to beginning.
How can I programatically open a new message window in the default email client (such as Outlook) using Windows API calls? I will need to include an attachment and would prefer to specify the default message body in 'rich text' (ie. not plain) format.
The ShellExecute solution is good for simple messages without attachments, but if you want more control over the process, you may try the MAPI; in particular, see the MAPISendMail function and the MapiMessage structure.
For even more complex needs, there's the extended MAPI, but I didn't find any documentation about it on the MSDN. However this seems to be a good wrapper around the extended MAPI.
I think you can do this using the ShellExecute. An attachment should be used as parameter: something like this but I don't remember for sure: "mailto:email#something?subject=subject&body=body&attachment=..."