CCSID in Message broker - broker

There is Source and Target applications understanding characters in different CCSIDs.
Source application is connected to queue manager of some default CCSID set.And Target application also connected to Queue manager with different CCSID set.
I need some clarifications on how these messages are passed and retrieved.
1)Source application places messages in its Q.This message is in unreadable format.Since both have different CCSID,I hope MQPUT will provide CCSID which is overriden by Source QM's default CCSID.-Please correct if wrong
2)WMB receives the message in MRM format.It parses according to the physical and logical structure specified.-Please clarify whether data conversion happens at this stage itself according to the Target application's CCSID? If not,then how would be the message in readable format when it comes out of message broker?.
3)WMB after parsing sets the OutputRoot.properties for CCSID and Encoding according to the target application's CCSID.Please correct if wrong
4)Finally ,as Target application gets the message MQGET with some CCSID ,it overrides the Target QM's CCSID.Please correct if wrong

If this 2 messages are MRM, you dont need to create 2 Msets, you can use the same.
In Mapping node you can change the CCSID just assigning a value , but you need to know what CCSID is (like 819, 1208 etc...).
You can use ESQL to change CSSID too.
Set OutputRoot.Properties.CSSID = 819;
3) WMB will not change CCSID or Enconding according to the target, WMB cant know what target is waiting for.
4) Yes, when you receive a message, WMB will take enconding and CCSID and overrides it. (You can see it at OutputRoot.Properties).

Creating 2 message sets . one having message set of input type and secondhaving message set of output type .
Set output node message domain as per message set defined to it
Set input node message domain as per message set defined to it
Using map node in between input node and output node will be able to map the contents .
Thanks
Aravind

Related

AUTOSAR configuaration - DCM module

I am stuck at a point where I am configuring the DCM module and the current parameter I am trying to configure DcmTimStrP2AdjustServer,
The requirement is P2CAN_SERVER_MAX = 25ms; P2STARCAN_SERVER_MAX = 5000ms;
Is DcmDspSessionP2ServerMax the same as P2CAN_SERVER_MAX? and if it is the same
What is the need for DcmTimStrP2AdjustServer and how do I find the best value for DcmTimStrP2AdjustServer.(The values all should be a multiple of DcmTaskTime which I find to be logical).
DcmTaskTime = 5ms;
I am following Autosar 4.0.3, using ETAS tool for configuring the parameters.
To fulfill your requirement, you need to configure respectively
DcmDspSessionP2ServerMax & DcmDspSessionP2StarServerMax for each session control in the DcmDspSessionRows at Dcm/DcmConfigSet/DcmDsp/DcmDspSession/.
i.e.
DcmDspSessionP2ServerMax 25
DcmDspSessionP2StarServerMax 5000
There is no DcmTimStrP2AdjustServer, but I guess you're referring to DcmTimStrP2ServerAdjust instead. DcmTimStrP2ServerAdjust & DcmTimStrP2StarServerAdjust should be configured to a multiple of your DcmTaskTime (5ms in your case, so i.e. 5ms, 10ms, 15, ms, ... is applicable) and are used to safeguard that the response is available on the bus before triggering the P2 or P2* timeouts. In your case you may want to set these values to the same values as in the DcmDspSessionRows if there is no other specification given, because the chosen timeout values there are already multiples of your DcmTaskTime:
DcmTimStrP2ServerAdjust 25
DcmTimStrP2StarServerAdjust 5000
The adjust value is an internal value, in order to adjust the delay between the Dcm Transmit Request and the message being actually on the Bus.
The definition of P2ServerMax and P2*ServerMax and their corresponding Adjust values is the same:
This parameter is used to guarantee that the diagnostic response is available on the bus before reaching P2 by adjusting the current DcmDspSessionP2ServerMax. This parameter mainly represents the software architecture dependent communication delay between the time the transmission is initiated by DCM and the time when the message is actually transmitted to the bus

Importing data from multi-value D3 database into SQL issues

Trying to use the mv.NET by bluefinity tools. Made some integration packages with it for importing data from a d3 multi-value database into MS SQL 2012 but seem to be having some trouble with the mapping.
For the VOYAGES table have some commentX fields in the D3 application that are acting quite unwieldy and the INSERT fails after a certain number of rows with the following message
>Error: 0xC0047062 at INSERT, mvNET Source[354]: System.Exception: Error #8: dataReader[0] = LTPAC002 ci.BufferColumnIndex = 52, ci.ColumnName = COMMGROUP(Error #8: dataReader[0] = LTPAC002 ci.BufferColumnIndex = 52, ci.ColumnName = COMMGROUP(The value is too large to fit in the column data area of the buffer.))
at mvNETDataSource.mvNETSource.PrimeOutput(Int32 outputs, Int32[] outputIDs, PipelineBuffer[] buffers)
at Microsoft.SqlServer.Dts.Pipeline.ManagedComponentHost.HostPrimeOutput(IDTSManagedComponentWrapper100 wrapper, Int32 outputs, Int32[] outputIDs, IDTSBuffer100[] buffers, IntPtr ppBufferWirePacket)
Error: 0xC0047038 at INSERT, SSIS.Pipeline: SSIS Error Code DTS_E_PRIMEOUTPUTFAILED.The PrimeOutput method on mvNET Source returned error code 0x80131500.The component returned a failure code when the pipeline engine called PrimeOutput().The meaning of the failure code is defined by the component, but the error is fatal and the pipeline stopped executing.There may be error messages posted before this with more information about the failure.
The value is too large to fit in the column data area of the buffer. -> tried changing the input / outputs types but can't seem to get it right.
In the SQL table the columns are of type ntext.
In the .dtsx job the data type for the columns are of type Unicode String [DT_WSTR] with length 4000 , I guess these are auto-detected.
The import worked for other D3 files like this not sure why it fails for these comment fields.
Running the query on the mv.NET Data Manager ( on the d3 server) times out after 240 seconds so maybe this is the underlying issue?
Any ideas how to proceed? Thank you ~
Most like reason is column COMMGROUP does not have correct data type or some record in source do not fit in output type
To find error record (causing) you have to use on redirect row (property of component failing component ) and get the result set in some txt.csv /or tsv file .
then check data
The exception is being thrown from mv.NET so I suggest you call (or ask your reseller) to call Bluefinity support and ask them about this. You're paying for support, might as well use it. Those programs shouldn't be allowed to throw exceptions like that.
D3 doesn't export Unicode, that might be one issue. But if the Data Manager times-out then I suspect something is wrong in the connectivity into D3. Open a Connection Monitor from the Session Monitor and watch the connection when you make the request. I'm guessing it's either hanging or more probably it's falling into BASIC Debug.
Make sure all D3-side programs related to this are either all Flash-compiled, or all Not Flashed. Your app code will fall into Debug if it's not Flashed but MVNET.BP is.
If it's your program that's in Debug, fix it. If you're not sure which program it is, LIST-RUNTIME-ERRORS in DM.
If it's a MVNET.BP program, again work with Bluefinity. If you are using MVSP for connectivity then the Connection Monitor may be useless, you'll need to change that to an IP (Telnet) connection to see the raw data exchange.

Unable to retrieve header field SenderCompID , 142 from de-serialized Quickfixj Quote messase

Our FIX Engine implemented in QuickfixJ send the received quote message in the quote session to another application listening on JMS queue for further processing like persistig to DB.
The message serialized and de-serialized using Apache serializationUtils.
The problem is, the application throws FieldNotFound error when it attempts to retrieve SenderCompId header field from the de-serialized message.
setSenderlocid(header.getField(new SenderLocationID()).toString())
quickfix.FieldNotFound: Field [142] was not found in message.
at quickfix.FieldMap.getField(FieldMap.java:216)
at quickfix.FieldMap.getFieldInternal(FieldMap.java:353)
at quickfix.FieldMap.getField(FieldMap.java:349)
Does serialization work with QuickFixJ messages?

What is the correct SMPP error code to indicate corrupt/invalid UDH field values?

I'm trying to handle UDH data for multipart messages and I want to use an appropriate error code when there's a problem with the multipart fields. There are several error codes for bad TLV's, but I don't see anything except generic failure messages that I could use for UDH. Is that the best I can do here, or is there a more direct message I could use?
Your observation is correct - there is not a single error defined for UDH.
If you want, you can use error codes from reserved section and assign specific meaning to one/some of them. I think the "Reserved for SMSC vendor specific errors" (0x400-0x4FF) can be a good candidate.
Actually it looks to me like ESME_RX_R_APPN = 0x66 "ESME receiver reject message error." is the best error code to throw here.
It should correspond to a permanent error for this message only and let further messages be processed.

Parsing structured syslog with syslog-ng

I am trying to leverage the parsing of structured data feature in syslog-ng. From my firewall, I am forwarding the following message:
<14>1 2012-10-06T11:03:56.493 SRX100 RT_FLOW - RT_FLOW_SESSION_CLOSE [junos#2636.1.1.1.2.36 reason="TCP FIN" source-address="192.168.199.207" source-port="59292" destination-address="184.73.190.157" destination-port="80" service-name="junos-http" nat-source-address="50.193.12.149" nat-source-port="19230" nat-destination-address="184.73.190.157" nat-destination-port="80" src-nat-rule-name="source-nat-rule" dst-nat-rule-name="None" protocol-id="6" policy-name="trust-to-untrust" source-zone-name="trust" destination-zone-name="untrust" session-id-32="9375" packets-from-client="9" bytes-from-client="4342" packets-from-server="7" bytes-from-server="1507" elapsed-time="1" application="UNKNOWN" nested-application="UNKNOWN" username="N/A" roles="N/A" packet-incoming-interface="vlan.0"]
Based on the format of the IETF logs, it appears to be correct, but for some reason the structured data is actually being parsed as the message portion of the log and not being parsed as structured data.
On the syslog-ng side, you need to use either a syslog() source, or a tcp() source with flags(syslog-proto) set, and then the stuff will end up in variables like ${.SDATA.junos#2636.1.1.1.2.36.reason} and so on and so forth, which then you can use as you see fit.