How to handle the special characters in OSB 11g.
I am getting special characters from Mainframe and wherein the jave application placed into Queue and hence I consumed the Request from queue and process to further action .But I got the special characters so how I can handle into OSB 11g.
I am happy any one can help us.
Thanks,
OSB implements UTF-8 by defult which take cares almost all special characters. If you dont want your message to be parsed then better use CDATA. Here assuming that message is XML document as not mentioned in question.
Related
I am going to ask very basic question of difference between EML and MSG file stack. But I am not expecting "MSG is outlook-understandable format" as an answer. I need to know, if I am using EML what properties, I won't be able to extract. I am fairly familiar with OLE and MIME
I am writing a metadata extractor that will get integrated with SOLR. I am using EWS(Exchange Web Services) which is quite easy to use with many advantages and disadvantages.
This question is to summon all Exchange Experts to shed some light on EML or MSG. I have tried endless blogs but none is explaining why to choose what for now.
Reference: Difference between a .msg file and a .eml file
Note: I don't want to convert EML to MSG or vice versa. I will be happy to use any of the component.
Okay so given your last comment your actual question is about the Message Body so you don't need to worry about MSG vs EML. Exchange stores bodies in one of three formats either Text, HTML or RTF (or a combination of these) and it will perform an on the fly conversion if a client asks for a specific format and that is not available. I would say for what you doing just use HTML (which is the default format EWS will return) and you won't have problem. Its pretty rare for people these days to use RTF (HTML has been the default format in Outlook since 2000).I would suggest reading https://msdn.microsoft.com/en-us/library/cc463905(v=exchg.80).aspx . The only time I could see you losing format in the body if you go with HTML is if you have RTF messages with embedded Ole objects but this is pretty rare for people to use these days.
Cheers
Glen
I'm working on a message pipeline in Apache Camel and could use some input on the design. Basically, messages are coming into the pipe and need to get stored somewhere before a human triggered process manually approves/rejects each message. I want something that is resilient so that even if the system goes down the messages wouldn't be lost.
I was thinking of converting each message into a short text file and having camel consume that text file. But this way seem pretty clunky. Does anyone know of a better way of doing it?'
Thanks!
use JMS/ActiveMQ for reliable asynchronous messaging...integrates easily with Camel and other applications that need to produce/consume message based data (text, xml, serialized, etc)
Does anyone had accomplished this?.
The big picture would be to develop the entire asterisk GUI from filemaker, but right now I'm asking you help to connect both.
Asterisk controls our entire Call Center. I would like the info from incoming calls and queues to be written in a FileMaker database.
Disclaimer: I don't know the first thing about FileMaker. But, if it's like any other programming language (which from what I know, I'm not sure that's true) then let's look at the options on how we'd accomplish this generically with other programming languages...
If you just want the results of your call, the CDRs (call detail records), you can configure Asterisk to output custom CDRs in cdr_custom.conf (check it out if you'd generated the sample configurations)
Here's an example cdr_custom.conf:
[mappings]
Simple.csv => ${CSV_QUOTE(${EPOCH})},${CSV_QUOTE(${CDR(src)})},${CSV_QUOTE(${CDR(dst)})}
It will drop a file typically in /var/log/asterisk/ if you haven't changed it otherwise in your configuration.
Then, either restart asterisk, or more gracefully just reload the cdr module:
asterisk*CLI> cdr show status
asterisk*CLI> module reload cdr_custom.so
Using the resulting file, parse the CSV and format it in a friendly fashion for Filemaker / "your language of choice".
If you're looking for real-time information about calls, it does get more complicated. Probably for just reporting purposes, you can use the Asterisk AMI (Asterisk Manager Interface). (Canonical wiki page linked)
This is a TCP IP application, open a socket to it, and you're good to go. There's also the AJAM interface (Asynchronous Javascript Asterisk Manger). Which you can make HTTP calls to.
Lastly, if you want to do further processing during the routing of the call via the dialplan, you'd want to use AGI (Asterisk Gateway Interface) which is called from the dialplan, and is all over STDIO.
Actually you can create a ODBC connection to the asterisk databases and use filemaker to access the tables direct. It will give you a 'live' connection and save you all the import <-> export fuss. If you google on filemaker odbc you'll get results on setting this up, it works quite easy (not always fast depending on your query but certainly a lot quicker than the manual method)
I'm using mirth for sending and receiving HL7 message.
Is it possible to insert custom data (char datatype) in my SQL Server database by picking up a HL7 message (file type) mapping it with my columns of my database using transformer and inserting to my database.
And is there any option of generating status in a outbound HL7 message in mirth ?
You can use a destination connector type of Database Writer to write data from the input HL7 message to your database.
You can use a second destination connector to generate an output HL7 message based on the input.
You mentioned status -- can you be more explicit? What status, from the database call or something else?
You could add a ZZZ segment to the outbound message to hold whatever status information you need to send.
EDIT:
Here's how to use javascript to add a ZZZ segment.
createSegment('ZZZ', msg);
msg['ZZZ']['ZZZ.1']['ZZZ.1.1'] = "This is ZZZ.1"; // These are a pain to type!
msg['ZZZ']['ZZZ.2']['ZZZ.2.1'] = "Field ZZZ.2 can contain whatever you want";
msg['ZZZ']['ZZZ.3']['ZZZ.3.1'] = "such as date, time, results of database update";
The UltraPort MS SQL Schema Engine does exactly what you're looking for. That's all that it does, it's very fast and very good at it, and has free fully functional trial. It sets up in literally minutes and they've got really good customer service. If you call in they'll walk you through a 10-15 minute example of importing HL7 messages (and actually encourage you to use your own HL7 data if you have any). 10-15 minutes will answer 90% of any questions you might ever have and it includes downloading and installing the software.
Home Page: http://www.hermetechnz.com/EasyHL7/prod_sql.asp
Online Help: http://www.hermetechnz.com/Documentation/UltraPort/MSSQL/index.html
It stores both the unparsed HL7 message as well as breaking it into parsed data tables as well as (optionally) storing the unparsed SEGMENTS as individual rows.
Also, you can easily customize the HL7 Version definitions to include "Z" segments or custom datatypes used by specific vendors.
Hope this helps.
I have a form that accepts text and is posted to the server.
If a user were to input a French character such as 'à', it will be read as 'Ã' by Classic ASP code and be stored as 'Ã' in a SQL Server 2005 database.
A similar affect happens to other accented characters. What's happening?
It's a problem of character encoding. Apparently your server and database are configured with charsets Windows-1252 or ISO-8859-1, and you're receiving UTF-8 data.
You should check that your server sends a Content-Type or a Content-Encoding header with values ending with "charset=iso-8859-1".
I guess your server doesn't send the charset of the documents, and people with default configuration set to UTF-8 send UTF-8 characters which are stored as iso-8859-1 (or Windows-1252) in your database.
See my answer here for the detail on what is likely happening.
Utlimately you need to ensure the encoding used in the form post matches the Response.CodePage of the receiving page. You can configure the actual character set sent by a form by placing the accept-charset attribute on the form element. The default accept-charset is the documents char-set.
What exactly do you have the ASP files codepages set to (both on the page containing the form and the page receiving the post)?
What are you setting the Response.CharSet value to in the form page?
I have just gone around in circles trying to fix this once and for all in my old classic asp app which uses jquery ajax posts to store info in a database. Tried every combination with no luck..
Ended up modifying any sql selects by using the stored proc mentioned here and magic happened. Data is still stored corrupted in the database, but is displayed correctly on the site.