permafrost / tundratn Goto Github PK

Check queue state inside task processing loop, and if disabled or suspended exit the loop. This will ensure queue processing stops as soon as possible after a queue is disabled or suspended.

If a previous derivative already exists, then do not create a new one - add a comment to the activity log stating that the existing derivative itself should be reprocessed if required.

This would negates the need for filter services in the majority of cases.

This can be used to extract the user that submitted the document to a document attribute, which can then be used in a processing rule's extended criteria etc.

If we enable duplicate check at document type/processing rule level, webMethods checks for duplicates and add it to bizdoc/Errors and a activity log entry and continues with processing. We still have to check for bizdoc/Errors for duplicate error and stop processing in the processing service.

Can we add the duplicate check logic in either process, derive, translate, deliver services to check duplicate in bizdoc/Errors document based on duplicate check flag.

Add a 'strict' mode to each top level service. When in 'strict' mode, if the bizdoc has any errors the service will refuse to process it, and mark the bizdoc with user status 'ERROR'.

Add a service to clear a TN queue of all documents/tasks.

Add $type/TypeID and $type/TypeName optional inputs, and if no ParsingSchema or recordBlueprint exists in the given $type document, then retrieve the document type from TN using TypeID or TypeName. This will let the service work in two modes, firstly where the document type has already been fetched and is passed whole to this service, and secondly where only the document type id or name is known when this service is called.

Rather than overloading the use of the $service processing service, which is used to process the original bizdoc, add another input that lets you specify a list of services that will be called to augment the list of document derivatives that need to be created.

A normal bizdoc processing service would implement wm.tn.rec:ProcessingService, which uses wm.tn.rec:ProfileSummary for sender and receiver.

One solution is to change tundra.tn.profile:get to return a document that is a super set of wm.tn.rec:ProfileSummary and wm.tn.rec:Profile, that way it'll work for both normal bizdoc processing services, and anything that's already been built to rely on the current tundra.tn.queue:each functionality.

Looking up a partner profiles by External ID should not query the database if the profile is already cached.

Instead of removing the username and password, just redact the password in the logged URL so that some evidence of the authority used remains.

This can be used to fix the sender or receiver of a document type to be a specific partner profile.

tundra.list.string:drop should have an output stringList variable called $list, otherwise, you need to either:

• have a separate MAP step to map $list to whatever was the input to tundra.list.string:drop (unless it was mapped to $list prior to invoking tundra.list.string:drop)
• add a design-time output variable to tundra.list.string:drop to map it to the required pipeline variable

If the source and target bizdocs are already full bizdoc objects, do not refetch them from Trading Networks.

The URL being delivered to gets logged against the bizdoc's activity log as follows:
[host]: Service 'tundra.tn:deliver' attempting to deliver document to 'http://user:password@server/path/file'.

This logging should be changed to redact the password.

Hi Lachlan,
Is there any chance of you creating a service to delete ContentPart from a given $bizdoc in TundraTN. This would be the opposite of AddContentPart. During testing, using Save/RestorePipeline, when I AddContentPart (using tundra.tn.document.content:add) to a $bizdoc I can only use the saved pipeline once. This would be a handy feature to be able to delete content part from a bizdoc for testing purposes

Cheers,
David

TN doesn't currently support parsing an xs:date that includes a timezone. This service would provide a workaround for this limitation.