Search results for query: *

Hello Jonbert, thought I might find you here causing trouble ;-) The efficiency issue revolves around the loading of adapters into memory. If you specify an adapter in the output card of a map then the event server can preload it. If you are using PUTs and GETs then the adapter type is...

There are a few things to try; - Keep your input type trees simple. Although for future proofing or correctness you may want your type trees to reflect your data structure, it is more efficient to lump things that you are mapping 'as is' from input to output in a single object. Switch on input...

You could use PUT statements. Your Output card needs to have a group object, so that multiple output items can be built. Why don't you want to use RUN maps?, they would be more efficient than PUT statements.

If this rule is in a single object field (and I'm guessing that it probably is) then it will only be calling the Generic Email map once. You can check this my checking the Execution Audit logs. I think the problem is with the Generic Email map. It looks as if your generic email map is building...

The number of emails that you send per 'unit' of input will depend upon the structure of your output card type tree, and/or the Fetch mode of your input card. If the input card is in Integral mode then all of the input data will be read before any output is built (so you will read all of your...

ekmir is right. If you don't have a source defined for the input cards then the map becomes a functional map. Switch to list view in the Map designer as it will disappear from the Composition view. This can be a pain, as if you are calling the map from a RUN command and overriding the input...

We've gone for ../merc65/<env>/apps/<app_name>/ where env is the environment (dev, uat.. etc) and then /auditlogs /adapterlogs /data/ /dbint /maps /scripts /trees /workfiles The directories under /data contain sub dirs depending upon the app requirements to hold all the working business data...